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ABSTRACT 


The  creation  of  a  Massive  Data  Analysis  System  (MDAS)  will  enable  new  modes  of  science 
through  improved  management  tools  for  scientific  data  sets,  computational  methods,  and 
computational  resources.  To  provide  these  capabilities,  MDAS  researchers  are  developing 
a  software  infrastructure  to  support  data  location  transparency,  access  transparency,  and 
conversion  transparency  in  a  heterogeneous,  distributed  systems.  This  requires  a  scalable 
software  infrastructure  that  can  manage  petabytes  of  data,  support  rapid  access  of  selected 
data  sets,  and  provide  support  for  subsequent  computationally  intensive  analyses.  The  sys¬ 
tem  must  automate  the  collection  of  metadata  describing  data  sets,  computational  methods, 
resources,  and  users.  Some  of  the  core  technologies  being  used  to  provide  this  functionality 
include  object-relational  database  systems,  archival  storage  systems,  parallel  I/O,  third- 
party  transfers,  and  method-level  authentication.  By  supporting  transportable  methods  for 
manipulating  the  data,  it  then  becomes  possible  to  analyze  selected  data  sets  on  remote 
systems.  The  MDAS  becomes  an  infrastructure  to  build  next -generation  operating  and 
scheduling  systems  which  can  manage  the  flow  of  data  and  computation  across  distributed 
resources. 


IX 


Chapter  1 


Task  Objectives 


MDAS  is  an  information  discovery  system  that  supports  queries  against  metadata  stored 
for  users,  methods,  data  sets,  and  resources.  A  request  for  processing  of  data  can  be 
issued  based  entirely  on  the  objective  of  the  researcher.  The  information  discovery  system 
determines  the  names  of  the  data  set  and  the  methods  that  need  to  be  applied  to  the  data 
set,  the  locations  of  the  data  set  and  method,  and  the  identity  of  the  computer  resources 
that  could  be  used  to  execute  the  methods.  The  result  is  a  program  graph  that  can  be  given 
to  a  scheduler  and  then  to  an  execution  environment.  All  data  set  accesses  are  represented 
as  invocation  of  methods.  This  results  in  a  seamless  link  to  information,  driven  by  user 
needs. 

The  overall  objective  of  the  Massive  Data  Analysis  System  is  the  construction  of  a  scalable 
system  that  integrates  data  management  with  computation  to  support  analysis  and  assim¬ 
ilation  of  arbitrarily  large  data  sets.  The  initial  goals  for  the  project  were  the  development 
of  consensus  on  (a)  application  requirements,  (b)  hardware  and  software  systems  that  can 
meet  the  application  requirements,  (c)  and  the  application  presentation  interfaces  needed 
to  make  the  system  accessible  to  researchers.  These  goals  have  been  met. 

Currently,  MDAS  researchers  are  concentrating  on  the  implementation  of  the  software  de¬ 
sign,  the  use  of  real  applications  to  test  the  implementation,  the  integration  of  archival 
storage  with  database  management  systems,  and  the  involvement  of  a  commercial  software 
vendor.  Integrated  data  and  object  handling  systems  have  the  potential  to  be  the  next 
major  software  infrastructure  in  the  evolution  of  computer  systems.  If  designed  correctly, 
the  data  handling  system  can  support  a  uniform  user  interface  to  distributed  heterogeneous 
systems  needed  for  global  computing.  The  data  handling  system  acts  as  a  scheduling  system 
that  resides  above  the  operating  system.  Users  interact  directly  with  data  attributes,  rely¬ 
ing  on  the  data  handling  system  to  locate  the  data,  move  the  data  to  appropriate  compute 
resources,  and  execute  applications  on  the  data  sets. 


Chapter  2 


Technical  Problems 


The  primary  challenges  in  the  MDAS  project  are  (a)  the  integration  of  data  management 
systems  with  archival  storage  and  (b)  end-user  solutions  for  the  replacement  of  the  (Unix) 
file  paradigm  with  a  higher-order  interface  to  data,  methods,  and  resources. 

At  project  onset,  database  management  systems  (DBMSs)  and  hierarchical  (archive)  storage 
systems  (HSSs)  were  not  interoperable.  Replacements  for  the  Unix  OS  file  paradigm  existed, 
but  only  on  single-user  systems  and  largely  without  high-order  interfaces  to  resources.  In  or¬ 
der  to  develop  concrete  extensible  solutions  with  reasonable  technology  transfer  attributes, 
we  have  taken  a  two-pronged  approach  to  these  problems.  First,  we  rely  heavily  on  applica¬ 
tion  prototypes  to  investigate  the  viability  of  possible  solutions  to  the  primary  challenges. 
Second,  we  continue  to  carry  out  an  in-depth  research  into  the  design  and  specification  of 
production-grade  software  solutions.  A  number  of  technical  problems  have  emerged  from 
these  efforts  which  we  will  address  throughout  the  remainder  of  the  project: 

1.  Hierarchical  storage  system  (HSSs)  have  a  limited  number  of  I/O  channels  and  phys¬ 
ical  read/write  heads  for  archival  (tape)  storage.  Therefore,  an  application  with  large 
resource  requirements  can  easily  monopolize  the  entire  storage  system  unless  a  rea¬ 
sonable  resource  management  policy  is  implemented  in  the  HSS.  This  amounts  to 
implementing  a  queuing  system  within  the  HSS  to  mitigate  requests  from  multiple 
clients. 

2.  HSS  software  interfaces  contain  general  I/O  routines  such  as  read,  seek,  rewind,  etc. 
However,  most  HSS  application  client  interfaces  limit  data  transactions  to  file  get  and 
put — primarily  to  keep  applications  from  monopolizing  resources.  For  example,  an 
application  controlling  a  tape  drive  with  seeks  and  rewinds  for  2  hours  leads  to  poor 
resource  utilization  for  the  general  user  population.  This  means  that  when  an  HSS 
client  wants  to  read  a  large  file,  it  must  have  either  (a)  enough  local  memory  (RAM  or 
Disk)  to  read  the  file  in  total,  or  (b)  access  to  an  intelligent  spooler  which  can  buffer 
the  read  and  make  incremental  calls  to  the  HSS  for  large  file  blocks.  The  latter  case 
is  most  common. 

3.  The  development  of  an  MDAS  software  infrastructure  for  general  I/O  interoperabil¬ 
ity  between  local  and  remote  resources  requires  (a)  library  interfaces  to  individual 
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resources,  (b)  a  high-level  interface  to  hide  individual  resource  semantics  from  the 
users,  and  (c)  a  high-level  interface  that  supports  multiple  I/O  paradigms  across  each 
supported  resource.  Not  all  platforms  will  have  suitable  library  interfaces  for  all  re¬ 
sources;  e.g.,  a  desired  DBMS,  HSS,  or  HTTP  library  might  be  missing.  Hence, 
daemons  must  be  developed  to  assist  application  clients  on  those  platforms.  Further, 
the  build  environment  for  the  MDAS  software  can  become  arbitrarily  complex  without 
careful  design  considerations.  Rather  than  “port”  the  MDAS  software  to  each  ven¬ 
dor  hardware  platform,  the  MDAS  build  environment  should  support  compile-time 
configurable  options  for  drivers  to  various  resources. 

Supporting  a  a  high-level  interface  to  hide  individual  resource  semantics  from  users 
requires  the  development  of  intermediate  buffering  mechanisms  just  below  the  appli¬ 
cation  level.  For  example,  supporting  a  {  read,  seek,  rewind  }  paradigm  on  top  of 
a  dataset  opened  (transparently)  on  an  ftp  resource  will  require  local  buffering  and 
possibly  remote  re-reads  of  the  file.  A  related  issue  is  the  support  of  legacy  software 
systems;  e.g.,  the  use  of  Fortran  unit  numbers  for  I/O  transactions  on  a  DBMS  large 
object,  or  the  transfer  of  two  valid  file  handles  to  a  third-party  data  mover  for  a 
Unix-style  “pipe”  transaction. 

Tension  also  exists  between  items  “b”  and  “c”  when  a  paradigm  from  one  I/O  source 
(e.g.,  DBMS  query)  does  not  match  paradigms  supported  by  another  (e.g.,  Unix  fifo 
pipe).  Therefore,  categories  of  I/O  paradigms  need  to  be  identified  and  then  supported 
by  categories  of  high-level  semantics. 

4.  Among  the  key  resources  that  will  be  supported  by  MDAS  are  archival  storage  systems 
with  a  database  system  front-end.  The  database  systems  are  used  to  store  metadata 
and  to  provide  access  to  the  archive  data  sets.  However,  depending  on  the  particular 
database  system  used,  the  implementation  of  this  interface  may  be  different.  In  or¬ 
der  to  insulate  MDAS  methods  from  such  implementation  issues,  the  MDAS  system 
must  provide  appropriate  mappings  from  the  standard  file  I/O  interface  used  by  the 
methods  to  the  actual  interface  supported  by  each  database  system  front  end. 

5.  Application  clients,  DBMSs,  and  HSSs  all  have  response  time  limitations  for  I/O  and 
general  communication  transactions.  Coupling  these  systems  requires  careful  design 
considerations  to  avoid  request  timeouts  and  blocked  (hung)  communication  requests. 
For  any  particular  component  in  the  system,  it  is  worthwhile  to  know  in  advance 
that  another  component  is  off-line — rather  than  to  wait  on  an  internal  (possibly  long) 
connection  timeout  condition. 

6.  Application  clients,  servers,  DBMSs,  and  HSSs  all  have  various  authentication  mech¬ 
anisms  which  can  vary  among  sites.  In  a  distributed  environment,  it  is  often  desirable 
to  transfer  methods  and/or  datasets  from  one  resource  to  another  for  more  efficient 
processing.  This  capability  requires  authentication  interfaces  between  coupled  systems 
(e.g.,  a  tightly  coupled  DBMS  and  HSS)  plus  third  party  authentication  mechanisms 
to  permit  a  server  to  transfer  a  client’s  request  to  an  external  (third  party)  processing 
system. 

7.  Object-oriented  (  00)  software  technologies  greatly  simplify  the  task  of  software  engi¬ 
neering  and  hold  great  promise  for  software  reuse.  However,  present-day  00  compilers 
do  not  produce  high-performance  executables  which  is  of  paramount  importance  to 
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this  project.  Hence,  MDAS  implementations  should  choose  application-efficient  lan¬ 
guages  while  providing  interfaces  to  00  language  semantics. 

8.  Applets  (as  implemented  in  the  Java  language)  and  other  interpreted  methods  ex¬ 
tend  the  00  paradigm  to  remote  resources.  However,  applets  are  extremely  slow  in 
processing  scientific  datasets  or  performing  moderate  iterative  tasks  in  general.  For 
applets  to  be  truly  efficient,  “just-in-time”  compilation  methods  are  desirable  on  the 
target  platform. 

9.  Traditional  DBMS  and  FTP  technologies  rely  on  sequential  I/O  streams  for  trans¬ 
ferring  data,  objects.  This  approach  has  been  demonstrated  to  give  relatively  poor 
performance  unless  aggressive  caching  strategies  are  developed.  The  concern  is  that 
focusing  on  just  caching  strategies  will  be  inappropriate  for  the  more  advanced  tech¬ 
nology  that  is  based  on  parallel  I/O  streams. 

10.  Scientific  applications  should  be  able  to  access  data  and  cache  it  locally  no  matter 
where  the  data  is  originally  located.  This  is  equivalent  to  requiring  a  catalog  or  expert 
system  with  universal  resource  name  (URN)  capabilities. 

11.  Support  for  parallel  I/O  streams  must  be  done  within  the  context  of  emerging  stan¬ 
dards.  This  requires  tracking  the  MPI2  10  effort  which  is  examining  issues  related 
to  message  passing  within  a  compute  platform  and  1/ 0  to  external  peripherals.  In¬ 
teroperability  between  MPI  and  non-MPI  processes  will  require  specialized  software 
interfaces. 

12.  The  design  of  appropriate  experiments  to  test  the  capabilities  of  the  proposed  system 
requires  independent  testing  of  individual  infrastructure  components.  This  requires 
dedicating  separate  portions  of  the  testbed  system  to  HSS  support  and  to  database 
support.  The  result  is  that  it  will  be  possible  to  quantify  the  memory,  disk  cache, 
and  I/O  requirements  independently  for  each  system,  and  then  quantify  what  the 
integrated  system  will  need  in  terms  of  hardware  resources  to  have  adequate  perfor¬ 
mance. 
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Chapter  3 


General  Methodology 


Scientists  have  an  ever-increasing  need  to  store,  access,  and  manipulate  unprecedented 
quantities  of  data.  Modern  data  manipulation  requirements  include  searches  for  correlations 
in  large  data  sets,  incorporation  of  empirical  data  to  improve  the  predictive  capabilities  of 
computational  simulations,  and  mining  of  existing  data  sets  to  derive  better  input  conditions 
for  new  calculations.  High  performance  data  assimilation  environments  [8]  require  new 
modes  of  operation  to  integrate  data  mining  and  supercomputing.  These  large-scale  and 
national-scale  problems  strain  our  current  infrastructure  and  motivate  the  development  of 
massive  data  analysis  systems. 

In  order  to  implement  a  system  that  can  meet  these  requirements,  mutually-scalable  tech¬ 
nologies  are  needed  in  parallel  data-handling  systems,  computational  servers,  local  area 
networks,  and  resource  scheduling  environments.  Further,  these  system  complexities  need 
to  be  presented  to  users  in  a  set  of  navigatable  hierarchies.  This  latter  criteria  insures  that 
a  novice  can  have  a  high  degree  of  success  in  using  the  system,  while  experts  can  achieve 
major  advances  in  analysis  and  resource  efficiencies. 

Other  efforts  in  this  area  have  focused  exclusively  on  scalable  I/O  [11,  3],  high-performance 
computation  [7].  high-performance  communication  [5],  digital  libraries  [10],  or  object-oriented 
software  integration  [6].  These  are  valuable  efforts  which  will  provide  an  experience  base 
for  future  system  integrations.  However,  in  order  to  be  successful,  we  need  to  address  all 
aspects  of  of  the  w4massive  data  analysis”  problem.  It  is  far  more  effective  to  design  these 
new-generation  systems  from  a  first  principles  approach,  while  taking  available  technology 
into  consideration. 

The  Massive  Data  Analysis  System  (MDAS)  provides  a  software  infrastructure,  including 
user-level  application  program  interfaces,  metadata  catalogs,  MDAS  engine  functions  and 
daemons,  and  MDAS  drivers,  to  enable  resource  discovery  and  to  identify  resources  for 
scheduling  computations  in  a  heterogeneous,  distributed  system.  The  objective  of  MDAS 
is  to  enable  the  construction  of  scalable  systems  which  integrate  data  management  with 
resource  management  to  support  storage,  movement,  analysis,  and  display  of  arbitrarily 
large  data  sets.  MDAS  is  being  used  as  one  of  the  software  components  of  the  Distributed 
Object  Computation  Testbed  (DOCT).  MDAS  provides  a  seamless  link  to  information;  a 
data  management  system  for  heterogeneous  data  resources. 
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MDAS  defines  four  types  of  system  entities,  viz.  Data  Set,  Resource,  Method,  and  User. 
Metadata  definitions  are  provided  for  each  type  of  entity.  The  system  maintains  metadata 
for  all  “registered”  entities  and  provides  the  ability  to  create,  update,  store,  and  query  this 
metadata.  The  metadata  is  used  by  the  system  to  perform  resource  discovery  and  resource 
scheduling.  Each  data  set  access  is  represented  by  an  access  method  which  can  be  scheduled 
as  a  part  of  the  overall  application.  Entities  can  be  registered  with  MDAS  at  installation 
time  or  by  authorized  users  during  the  life  of  the  system.  Applications  can  link  to  libraries 
which  provide  routines  for  accessing  the  metadata  as  well  as  for  accessing  MDAS  entities. 

The  type  of  metadata  maintained  by  the  system  is  an  extension  of  the  metadata  maintained 
by  typical  operating  systems.  The  specific  goal  in  MDAS  is  to  employ  this  metadata  to 
support  the  storage,  handling,  and  processing  of  massive  data  sets.  Applications  can  use 
the  MDAS  application  program  interface  library  to  access  registered  data  sets,  resources, 
and  methods.  To  serve  a  specific  application  request,  the  MDAS  engine  may  perform  a 
variety  of  actions  including:  (i)  invoking  an  underlying  method  or  sequence  of  methods,  (ii) 
allocating  a  set  of  resources,  (iii)  accessing  the  neccesary  data  sets,  (iv)  moving  data  sets 
from  storage  to  compute  resources,  and  back,  (v)  moving  data  sets  among  storage  resources, 
e.g.  for  caching  and/or  replication,  and  (vi)  plugging  in  built-in  “glue  ’  functions  to  move 
data  sets  between  methods. 


3.1  Transparency 


The  objective  of  the  MDAS  project  is  to  construct  a  prototype  of  a  scalable  system  which 
integrates  data  management  with  computation  to  support  analysis  and  assimilation  of  arbi¬ 
trarily  large  data  sets.  The  system  must  provide  the  ability  to  store,  transport,  and  process 
large  data  sets.  By  storing  metadata  and  providing  the  ability  to  represent,  store,  query,  and 
process  this  metadata,  the  system  is  able  to  integrate  heterogeneous  data  management  and 
computational  resources  in  a  distributed  system.  An  abstraction  of  the  services  available 
in  such  a  system  is  provided  by  supporting  various  types  of  transparencies. 

The  wide  range  of  services  offered  by  MDAS  are  accessible  from  a  set  of  application  program 
interfaces  (API’s).  These  API’s  provide  location  transparency ,  thereby  enabling  applications 
to  access  data  sets  based  on  their  attribute  values  rather  than  by  their  precise  location, 
such  as  URL  or  file  path.  In  addition  to  location  transparency ,  MDAS  provides  a  strong 
abstraction  of  the  distributed  system  by  supporting  (i)  Format  Transparency  which  hides 
the  details  of  data  set  formats  and  structure  from  the  application,  (ii)  Method  Transparency 
which  enables  applications  to  specify  high-level  computational  requests  that  automatically 
invoke  the  appropriate  method  (or  sequence  of  methods)  to  complete  the  request,  (iii) 
Resource  transparency  where  the  system  determines  the  set  of  resources  to  use  for  satisfying 
a  given  computational  request  rather  than  requiring  the  application  to  explicitly  state  this  as 
an  input  requirement,  and  (iv)  User  Transparency  which  allows  MDAS  to  serve  as  a  broker 
or  surrogate  and  utilize  resources  on  behalf  of  users  who  may  not  have  direct  resource 
authorization. 
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3,1.1  Location  Transparency 


A  data  set  can  be  identified  based  on  intrinsic  content  or  the  content  of  its  associated, 
application-specific  metadata,  rather  than  by  exact  location,  such  as  a  URL  or  file  path. 
This  feature  provides  location  independence  to  applications  and  also  allows  for  optimization 
of  data  set  accesses.  The  system  can  choose  the  least  cost  location  for  accessing  a  given 
data  set  if  the  data  set  is  cached  and/or  replicated  at  multiple  sites. 


3.1.2  Format  Transparency 

The  system  maintains  metadata  on  data  sets  as  well  as  on  function  (or  methods)  that 
operate  on  data  sets.  This  permits  MDAS  to  distinguish  between  the  form  and  content  of 
data  sets.  Multiple,  existing  data  sets  may  have  the  same  semantic  content,  but  may  differ 
from  each  other  in  terms  of  the  internal  representations.  MDAS  defines  a  change  of  format 
to  be  invariant  on  the  data  set  content.  An  example  is  a  text  file  which  may  be  converted 
to  tagged  HTML  format,  and  further  transformed  into  a  Postscript  file.  By  maintaining 
the  neccesary  metadata,  the  system  is  able  to  match  requests  for  data  sets  by  identifying 
the  one  with  the  correct  format,  or  by  applying  conversion  methods  to  convert  an  existing 
data  set  into  the  desired  format. 


3.1.3  Method  Transparency 

For  a  given  computational  request,  there  may  be  several  alternative  implementations  (i.e., 
executions  of  methods  on  resources)  which  provide  the  desired  functionality.  Given  a  high- 
level  request,  the  MDAS  library  is  able  to  compute  and  execute  an  optimal  or  near-optimal 
implementation  of  the  request  based  on  user-specified  (or  default)  performance  criteria.  In 
some  cases  MDAS  may  need  to  synthesize  a  sequence  of  methods  to  provide  the  desired 
functionality.  Where  possible,  metadata  is  maintained  regarding  speed-up  and  scale-up 
behavior.  These  features  of  the  system  are  referred  to  as  method  transparency.  Data  access 
is  viewed  as  the  invocation  of  a  method  appropriate  for  the  storage  resource  being  accessed. 
Method  transparency  implies  that  the  requestor  of  the  data  set  does  not  have  to  specify  the 
access  mechanism. 


3.1.4  Resource  Transparency 

LTsers  can  identify  specific  resources  for  the  execution  of  a  request  or  simply  ask  that  a 
request  be  abstractly  executed  on  a  resource  pool.  In  the  latter  case,  an  optimal  (or  near 
optimal)  set  of  resources  is  identified  by  MDAS  for  executing  the  request  according  to 
user-specified  (or  default)  performance  criteria.  Once  again,  this  is  achieved  by  maintain¬ 
ing  appropriate  metadata  on  resources  and  methods.  For  resources,  the  system  maintains 
metadata  on  histories  of  load  throughput,  estimates  of  queue  waiting  times,  and  functions 
to  access  current  resource  load  estimates. 


3.1.5  User  Transparency 


In  heterogeneous,  distributed  systems  one  can  expect  resources  to  belong  to  different  se¬ 
curity  realms  or  domains.  A  single  computational  request  may  involve  multiple  resources 
belonging  to  multiple  realms.  For  example,  a  data  set  may  be  moved  from  a  resource  at 
one  geographic  location  to  another  resource  at  another  location,  where  it  may  undergo  a 
conversion,  and  then  moved  to  a  third  location  where  it  is  processed.  All  of  these  resources 
may  operate  in  different  security  realms. 

If  the  user  submitting  the  original  request  has  been  initially  authenticated  by  MDAS  or 
one  of  its  methods,  the  MDAS  ticket  mechanism  can  be  used  to  ensure  that  subsequent 
accesses  to  all  the  resources  is  transparent  in  terms  of  authentication  and  security  actions. 
In  particular,  resources  may  receive  requests  directly  from  MDAS  and  might  not  be  aware 
of  the  identity  of  the  user  submitting  the  original  request.  Thus,  user  transparency  provides 
an  authentication  broker  service  that  allows  user  requests  to  be  processed  on  resources  to 
which  the  original  user  may  not  have  been  directly  authenticated.  Given  that  data  accesses 
are  represented  by  the  access  method,  user  transparency  is  achieved  by  authenticating 
interactions  between  methods. 

Providing  user  transparency  also  allows  the  MDAS  system  to  avoid  copying  data  sets.  For 
example,  when  a  user  requests  a  read-only  copy  of  a  data  set,  MDAS  simply  increments  the 
user  reference  counter  for  the  object  instead  of  performing  a  disk  copy.  In  this  manner,  the 
MDAS  '’User  Space”  concept  replaces  the  Unix  ’’home  directory”  paradigm.  (MDAS  has 
no  notion  of  files  and  directories,  except  in  the  context  of  data  set  storage  locations.  )  A 
’’User  Space”  is  defined  by  the  system  entities  referenced  by  a  user  and  is  not  necessarily  a 
physical  space  on  a  resource. 


Chapter  4 


Technical  Results 


The  MDAS  software  system  is  now  in  the  implementation  phase.  An  overview  of  the  MDAS 
architecture  is  given  in  section  4.1.  Application  scenarios  are  discussed  in  section  4.2.  A 
draft  tutorial  and  portions  of  a  user  guide  for  the  MDAS  Application  Program  Interface 
(API)  is  given  in  sections  4. 3-4.5.  Sections  4.6-4.10  comprise  the  main  sections  of  a  draft 
MDAS  API  Reference  manual.  Portions  of  a  draft  implementors  guide  are  given  in  sections 
4.11-4.13.  Executable  versions  of  MDAS  Library  routines  and  miscellaneous  tools  to  assist 
with  the  task  of  Catalog  metadata  registration  are  listed  in  section  4.14.  Optional  MDAS 
agents  and  service  brokers  are  discussed  in  section  4.15.  An  early  DBMS-Archival  Storage 
integration  effort  is  presented  in  section  4.16. 
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Figure  4.1:  Massive  data  analysis  system  components. 

4.1  MDAS  Architecture 

To  enable  transparent  use  of  resources,  methods,  and  data  sets,  MDAS  must  generalize 
disjoint  protocols.  As  such,  MDAS  is  middleware  that  supports  a  very  high-level  interface 
to  application  layers  while  maintaining  an  internal  layer  of  drivers  to  interface  with  ac¬ 
tual  system  components.  The  following  subsections  identify  system  components  commonly 
encountered  in  an  MDAS  computing  environment. 

4.1.1  System  Components 

A  generic  representation  of  a  computing  environment  is  given  in  figure  4.1.  This  diagram 
is  intended  to  represent  system  resources  and  services  that  users  might  encounter  in  a 
typical  computational  data  analysis  environment.  The  following  list  describes  some  of  the 
characteristics  of  the  resources  and  services  available  in  the  computing  environment  shown 


in  figure  4.1. 


•  A  “Logical  Interconnect”  may  be  an  intranet  or  internet  along  any  network  lines. 
Intra-  or  internets  may  exist  between  computational  servers. 

•  Components  represented  as  single  systems  may  in  fact  be  multiple,  distributed,  or 
overlapping. 

•  Web  and  DBMS  clients  are  special  instances  of  interactive  applications. 

•  Web  and  DBMS  servers  also  represent  enhanced  storage  services. 

•  A  Metadata  server  is  a  DBMS  that  stores  metadata  (both,  application-specific  meta¬ 
data  as  well  as  MDAS  system  metadata). 

•  A  Web  client  is  used  to  browse  and  download  moderate-size  data  sets  or  data  set 
segments.  A  DBMS  client  is  used  to  query  application-specific  metadata. 

•  Batch  applications  might  run  on  a  desktop  or  a  (remote)  computational  server. 

•  A  daemon  service  might  be  something  simple  like  a  print  spooler  or  X- Window  client — 
or  a  complex  task  scheduling  and  management  system. 


4. 1.1.1  Users/Clients 

MDAS  users  may  access  the  system  from  a  variety  of  sources  including  interactive  Web 
access,  direct  access  via  an  application  program,  and  access  via  a  DBMS.  Users  may  be 
anonymous  or  authenticated .  An  authenticated  user  is  one  who  has  previously  “registered” 
with  MDAS.  MDAS  provides  mechanisms  by  which  an  anonymous  user  may  use  the  Regis¬ 
tration  Services  of  MDAS  to  become  a  registered  user.  Non-registered  users  are  treated  as 
anonymous  users  and  all  anonymous  users  receive  default  levels  of  access  and  service  from 
MDAS. 


Along  with  authentication  information,  users  can  be  associated  with  level  of  service,  level  of 
access,  and  path  histories  of  method  invocation.  The  level  of  service  establishes  the  user’s 
priorities  and  resource  consumption  constraints  in  using  the  system.  Level  of  access  controls 
the  user’s  accessibility  to  resources  in  the  system.  The  user’s  patterns  of  use  of  the  MDAS 
system  are  cached  as  path  histories.  They  contain  information  on  the  nature,  frequency, 
and  relationships  of  accesses  to  data  sets,  resources,  and  methods,  to  enable  future  user 
requests  to  be  served  efficiently. 


4. 1.1. 2  Data  Sets 

Data  sets  are  MDAS  entities  accessed  by  methods.  These  include  raw  data  sets  stored  on 
disk  or  on  archival  system  (or  both),  data  stored  under  various  file  systems,  and  data  stored 
in  DBMS’s.  In  addition  to  standard  information  such  as  name,  location,  size,  format,  and 
access  control,  other  information  that  may  be  associated  with  data  sets  includes  partitioning 
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(especially  for  parallel  data  sets),  structure,  and  access  history.  As  mentioned  above,  a  data 
set  access  may  be  in  the  path  history  of  one  or  more  users.  Conversely,  a  data  set  itself  may 
be  associated  with  access  history  information.  The  path  and  access  history  information 
is  important  in  deciding  when  a  data  set  needs  to  be  “cached”  (e.g.  from  archival  store 
to  disk),  when  it  can  be  “swapped  out”,  or  when  it  needs  to  be  replicated  for  improved 
performance. 


4. 1.1. 3  Methods 

Methods  in  MDAS  include  programs,  macros,  and  utilities,  which  operate  upon  and  trans¬ 
form  data  sets  in  the  system.  These  may  be  user-specified  or  built-in.  Similar  to  other 
entities  in  the  system,  when  a  method  is  registered,  the  system  stores  metadata  describing 
the  method,  its  input/output  parameters,  its  speedup  and  scaleup  characteristics,  etc. 


4. 1.1.4  Servers 

In  the  category  of  MDAS  servers  we  include  computational  and  storage  engines  or  resources. 
These  entities  have  a  given  capacity  and  therefore  the  usage/consumption  of  these  resources 
needs  to  be  monitored  for  effective  scheduling.  This  includes  compute  engines  (parallel  and 
sequential),  visualization  engines,  interactive  systems,  and  disks.  It  also  includes  file  servers, 
DBMS’s,  and  archival  storage  systems.  MDAS  maintains  metadata  on  usage  of  servers. 


4. 1.1. 5  Metadata  Servers 


TBD. 

4.1.2  Authentication 

Applications  running  in  a  heterogeneous,  distributed  massive  data  analysis  system  may 
often  require  connections  to  resources,  methods,  and  data  sets  which  belong  to  different 
security  realms  or  domains.  Thus,  the  system  must  handle  issues  related  to  authentication 
and  security  in  this  environment.  A  typical  operating  system  provides  data  set  security 
by  maintaining  file  permissions  at  the  user  or  group  level.  In  addition,  most  operating 
systems  use  security  protocols  which  rely  on  passwords  and  the  fact  that  users  first  log 
in  to  systems  using  a  password  prior  to  starting  any  other  tasks.  However,  there  is  a 
wide  variety  of  service  security  models  that  a  system  may  support  including,  single  user 
model  (as  in  PCs),  dedicated  network  connections  (single  user  networks),  password  challenge 
(telnet  model),  “hard- wired”  or  pre-set  software  passwords  (software  equivalent  of  dedicated 
network),  friendly  host  tables  (Unix  model),  and  tickets  (kerberos,  ssh  model). 

The  ticket  model  is  used  within  MDAS  and,  functionally,  this  model  subsumes  the  other  se¬ 
curity  schemes.  The  semantics  of  tickets  is  based  on  a  point-to-point  authorization  protocol 
in  which  each  side  is  assumed  to  have  a  private  security  key  for  the  other,  plus  the  ability  to 


12 


Application 

Program 


MDAS 

Library 


Heterogeneous 

Protocols 


Application  Layers 

MDAS 

Daemons 

High-Level:  API 

Mid-Level:  Specialized  Program 

Development  Interfaces 

Low-Level:  Protocol  Services 
and  Internal  Procedures 

Streams  FTP  HTTP  SQL 

(Internals) 

Physical  Layers 

Figure  4.2:  MDAS  Library  placement  in  an  application  software  hierarchy 


generate  public  “tickets'”  which  can  be  decoded  by  the  other  party’s  private  key  for  access 
authorization.  Under  this  model,  a  passwordless  system  can  be  considered  to  have  null 
tickets.  A  password  challenge  system  can  permit  the  instantiation  of  tickets,  where  the  user 
changes  from  a  login+password  paradigm  to  a  ticket +login  paradigm.  Since  the  friendly 
host  table  model  is  another  instance  of  pre-set  software  passwords,  it  can  be  replaced  by 
either  null  or  automatically  generated  tickets.  Given  the  permission  to  execute  a  method 
to  access  a  data  set  and  then  to  execute  an  analysis  or  display  method,  MDAS  supports 
third-party  authentication  in  which  the  methods  directly  exchange  tickets  to  validate  the 
information  exchange. 


4.1.3  Software  Architecture 

The  system  software  architecture  is  composed  of  a  software  library  plus  optional  daemons. 
Figure  4.2  shows  a  software  hierarchy  indicating  the  relationship  of  MDAS  software  compo¬ 
nents.  The  highest  level  in  the  software  architecture  offers  an  application  program  interface 
(API)  to  external  applications.  The  middle  level  consists  of  the  MDAS  Library  which  pro¬ 
vides  the  mechanisms  to  store,  retrieve,  update,  and  act  on  metadata  maintained  by  MDAS. 
At  the  lowest  level,  MDAS  maintains  a  set  of  architecture  and  resource  specific  drivers  which 
provide  the  interface  between  MDAS  and  the  underlying  heterogeneous  environment. 

The  library  itself  may  contain  generic  system  functions,  e.g.  format  translation  algorithms, 
but  it  does  not  contain  application-specific  routines.  Instead  it  requires  that  such  methods 
be  “registered"’  as  MDAS  methods  which  will  then  be  invoked  as  needed.  This  highlights 
the  role  of  MDAS  as  a  broker  of  metadata.  The  MDAS  Library  is  expected  to  contain 
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several  value-added  methods  for  standard  format  translations,  spooling  operations,  etc. 
The  library  also  provides  drivers  to  interact  with  MDAS  service  broker  daemons.  These 
daemons  provide  access  to  services  which  may  not  have  been  implemented  on  a  particular 
architecture,  e.g.  the  IBM  DB‘2  database  system  on  SGI/Cray  T3E  parallel  computer. 
Thus,  applications  can  gain  access  to  such  resources  even  if  they  are  not  implemented  on 
the  local  system. 

MDAS  entities  (including,  data  sets,  methods,  resources,  and  users)  are  registered  in  the 
system  either  via  explicit  calls  to  the  appropriate  API’s,  or  as  a  side  effect  of  an  MDAS 
operation.  For  example,  data  sets  are  automatically  registered  when  a  new  data  set  is 
opened  for  write  with  an  MDAS  API  call,  or  when  the  system  creates  intermediate  result 
data  sets,  or  when  it  replicates  data  sets.  In  addition,  a  resource  that  is  new  or  unknown 
so  far  to  MDAS  is  registered  when  a  user  explicitly  connects  to  it  the  first  time. 

The  system  metadata  is  stored  in  a  distributed,  replicated  MDAS  Metadata  Catalog.  The 
locations  of  the  MDAS  Catalog  and  its  replicas  are  specified  at  system  installation  time  on 
a  per-site  basis.  Users  can  override  or  augment  the  default  catalog  information  at  run-time 
for  specific  resources. 
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4.2  Application  Scenarios 


This  section  illustrates  how  MDAS  services  can  be  used  in  a  variety  of  scenarios  involving 
analysis  of  massive  data  sets. 


4.2.1  Document  Text  and  Image  Processing 

This  scenario  illustrates  the  use  of  MDAS  services  for  handling  text  and  image  data,  with 
specific  applicability  to  the  types  of  applications  being  considered  in  the  DOCT  project. 


Patent  and  trademark  related  data  is  stored  in  archival  storage  systems  using  proprietary 
data  formats  (e.g.  Messenger  text  files).  In  order  to  index  these  data  sets  using  standard 
text  engines,  the  original  files  may  have  to  be  converted  to  standard  formats,  e.g.  SGML, 
tagged  files;  cleaned  up  so  that  all  records  in  the  file  are  in  the  same  format,  e.g.  remove 
leading/trailing  blanks;  and  processed  such  that  relevant  metadata  is  extracted  for  each 
file.  These  converted,  "cleaned”  files  can  then  be  used  to  create  text  indexes  and  populate 
database  systems  with  the  actual  document  data.  The  patent  files  also  contain  a  large 
number  of  images  stored  in  the  “Yellow  Book”  format.  These  files  are  processed  to  extract 
images  in  standard  formats,  e.g.  tiff  images,  and  store  the  link  between  images  and  patents. 


4. 2. 1.1  Handling  Text  Files 

Queries  issued  against  the  patent  database  may  involve  reading  the  processed  text  indexes 
associated  with  the  database,  as  well  as  reading  the  original  data  itself.  The  system  must 
provide  the  capability  to  read  this  data  regardless  of  whether  it  is  in  archival  storage  or 
disk,  on  the  local  system  or  a  remote  system. 

Methods  used  to  convert  data  from  archival  storage  to  a  form  that  is  suitable  for  indexing 
and  loading  in  a  database  can  be  registered  in  MDAS.  The  system  maintains  metadata 
associated  with  each  method.  An  application  can  issue  the  following  sequence  of  requests 
to  MDAS: 


1.  Connect  to  an  archival  storage  system  containing  files  for  a  particular  patent,  such 
that,  currently,  the  links  from  the  application  host  to  the  the  archival  system  are  least 
congested 

2.  Connect  to  a  database  that  currently  has  sufficient  storage  space  to  hold  the  informa¬ 
tion  for  this  patent 

3.  Connect  to  a  text  search  engine 

4.  Move  all  data  associated  with  this  patent  from  the  archive  to  the  database  and  index 
this  data  using  the  text  search  engine 
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MDAS  metadata  is  used  in  responding  to  the  above  sequence  of  requests.  For  example, 
the  system  keeps  information  on  contents  and  location  of  data  sets  and  the  current  state 
of  resources  which  allows  it  to  identify  the  archive  requested  in  the  first  request.  Similarly, 
it  stores  the  location  of  various  resources  such  as  database  management  systems  and  text 
search  engines,  and  their  states,  which  enables  it  to  respond  to  the  second  and  third  requests 
above.  Finally,  it  keeps  tracks  of  various  methods  available  to  it.  The  last  request  above 
prompts  the  system  to  search  for  methods  that  can  carry  out  the  neccesary  transformations 
on  the  data  sets.  Thus,  it  is  able  to  identify  the  appropriate  method(s)  to  invoke  on  the 
specified  data  sets  using  the  desired  set  of  resources  to  satisfy  the  user’s  requests. 


4. 2. 1.2  Handling  Image  Data 

Similar  to  the  text  data,  patent  files  also  contain  image  data  which  may  be  stored  in  archival 
storage  systems  and/or  disk,  and  which  may  be  indexed  based  on  image  features.  The  same 
sequence  of  requests  as  above  can  be  issued  against  image  files  related  to  a  particular 
patent.  In  addition,  there  may  be  other  types  of  processing  applicable  to  images.  For 
example,  consider  the  following  sequence  of  requests: 

1.  Connect  to  an  archival  storage  containing  image  data  for  a  given  subset  of  patents 

2.  Invoke  a  user  defined  parallel  method  which  performs  image  feature  extraction  and 
use  this  to  extract  all  images  which  satisfy  a  given  condition 

3.  Store  selected  images  in  a  database 

Metadata  associated  with  the  image  feature  extraction  method  allows  the  system  to  identify 
the  number  of  nodes  needed  on  a  massively  parallel  computer.  Based  on  the  data  set  sizes, 
the  system  may  also  identify  the  need  for  a  parallel  I/O  transfer  between  the  archival  storage 
system  and  the  parallel  computer. 


4.2.2  Scientific  Applications 

This  section  describes  a  variety  of  scientific  applications  which  can  benefit  from  the  services 
provided  by  MDAS. 


4. 2. 2.1  3-D  Ocean  Simulation  Environments 

Running  very  large  3-D  ocean  simulations  (as  done  by  NCCOSC,  the  Naval  Command  Con¬ 
trol  and  Ocean  Surveillance  Center),  is  both  computationally  intensive  and  data  intensive. 
Very  large  model  output  files  are  typically  generated  for  each  run.  Additional  data,  require¬ 
ments  might  include  storing  information  such  as  model  calibration  data,  observational  data 
for  validation,  etc. 
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Creating  a  historical  log  of  model  run  outputs  would  be  desirable.  Unfortunately,  current 
computational  simulations  are  often  rerun  from  scratch  in  order  to  reanalyze  output  data 
due  to  storage  limitations. 

Using  the  resource  metadata  of  MDAS  to  identify  systems  to  speed  up  the  simulation 
itself,  as  well  as  the  data  handling  and  storage  capabilities  of  MDAS,  to  store  model  input 
and  output  data  sets,  would  create  a  unique  modeling  archive  in  which  post-processing, 
comparing,  and  validating' of  output  data  would  constitute  a  modeling  audit  trail  suitable 
for  use  by  policy  makers  and  modelers  alike. 

Model  validation  tools  could  be  developed  in  this  framework  that  automate  the  validation 
process.  Defining  classes  of  statistical  tests  and  associated  calibration  data  sets  would  be 
an  important  step  in  increasing  model  result  confidence.  This  could  be  accomplished  in  the 
MDAS  framework  by  registering  user-supplied  validation  methods. 


4. 2. 2. 2  Climate  Data  Assimilation 

An  important  aspect  in  short-term  numerical  weather  prediction  and  long-term  climate 
modeling  is  incorporating  observational  data  into  simulation  systems  (data  assimilation). 
A  typical  climate  data  assimilation  scenario  might  involve  the  following: 

1.  Observations  of  the  weather  system  (coming  from  ground  stations,  satellites,  flying 
balloons,  and  other  sources)  are  collected  every  6  hours,  giving  a  record  of  what 
actually  happened. 

2.  A  forecast /simulation  model  starting  from  a  given  initial  condition  computes  succes¬ 
sive  forecasts  every  6  hours  for  every  point  of  some  regular  grid  (e.g.  2  x  2.5  degrees 
with  14-22  elevation  levels). 

3.  These  two  streams  of  events  (what  the  weather  should  theoretically  be  +  what  was 
actually  observed)  are  fused  together  by  the  data  assimilation  process,  which  produces 
a  more  optimal  data  set. 


More  accurate  forecasts  can  be  produced  by  using  the  assimilated  data  set  as  the  initial 
condition  in  computing  the  next  forecast,  leading  to  a  better  forecast  sequence. 

In  operational  environments,  data  assimilation  is  a  very  computationally  intensive  task  with 
real-time  requirements  specifying  that  all  calculations  be  completed  before  the  next  batch 
of  observation  data  comes  in  (6  hours  in  our  example). 

The  computation  and  storage  requirements  involved  make  this  a  challenging  problem.  The 
application  requires  access  to  distributed  archival  storage  systems  to  be  able  to  handle  the 
storage  requirements  and  proper  scheduling  of  tasks  on.  possibly,  multiple  parallel  engines. 
MDAS  discovery  and  resource  identification  services  can  be  useful  here. 
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4. 2. 2. 3  Digital  Sky  Survey 


Large-area  digital  sky  surveys  are  a  development  of  astronomical  research  that  can  also 
benefit  from  the  MDAS  environment.  Recent  large-area  surveys  in  optical,  infrared,  and 
radio  wavelengths  will  be  placed  online  for  use  by  the  astronomical  community.  Collections 
such  as  the  Digital  Palomar  Observatory  Sky  Survey  (DPOSS),  the  2-Micron  All  Sky  Survey 
(2-MASS),  and  the  NRAO  VLA  Sky  Survey  (NVSS)  represent  terabytes  of  data. 

Providing  access  to  catalogs  and  image  data  with  MDAS  infrastructure  for  accessing  dis¬ 
tributed  data  archives  will  allow  detailed  correlated  studies  across  the  entire  data  set. 
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4.3  API  Tutorial 


As  a  place  holder,  examples  have  been  included  from  the  reference  section. 

The  following  examples  assume  that  argv  and  argc  are  system-defined  variables. 


4.3.1  Catalog  Queries 

4.3.2  Fetching  Data 

PROGRAM  getk2 

MDAS.status  status 
MDAS_INFOH  dsinfo,  cacheinfo 

MDAS_INIT(argc,  argv,  NULL,  status) 

MDAS_INFO_CREATE (MDAS_DATASET ,  dsinfo,  status) 
MDAS_INFO_SET_ATTR(MDAS_NAME,  "fin.dat",  dsinfo,  status) 
MDAS_INFO_CREATE(MDAS_DATASET,  cacheinfo,  status) 
MDAS_INFO_SET_ATTR(MDAS_STOR_FMTN ,  ,lkhoros2M,  cacheinfo,  status) 
MDAS_GET (dsinfo,  cacheinfo,  status) 

MDAS_FINALIZE(NULL, status) 

END  PROGRAM 


4.3.3  Piping  Data  Sets 

PROGRAM  pipefun 

MDAS_ status  status 
MDAS.INFOH  funinfo,  psinfo 

MDAS_INIT(argc,  argv,  NULL,  status) 

MDAS_INFO_CREATE(MDAS_DATASET,  funinfo,  status) 
MDAS_INFO_SET_ATTR(MDAS_NAME,  "fun.dat" ,  funinfo,  status) 

MDAS_INFO_CREATE(MDAS_RESOURCE,  psinfo,  status) 
MDAS_INFO_SET_ATTR(MDAS_RSRC_TYPE,  MDAS.PRINTER,  psinfo,  status) 
MDAS_INFO_SET_ATTR(MDAS_RSRC_FMTN,  "postscript",  psinfo,  status) 

MDAS_INFO_PIPE(funinfo,  psinfo,  status) 
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print  "fun.dat  printed  at:" 

MDAS_INFO_PRINT (psinf o , status ) 

MDAS_FINALIZE(NULL, status) 

END  PROGRAM 

4.3.4  Executing  Requests 

4.3.5  Computing  with  User-defined  Formats 

4.3.6  Connecting  to  Resources 

PROGRAM  dbconnect 

MDAS_status  status 
MDAS.INFOH  dbinfo 
MDAS.SERVH  dbh 

MDAS_INIT(argc,  argv,  NULL,  status) 

MDAS_INFO_CREATE(MDAS_RESOURCE,  dbinfo,  status) 
MDAS_INFO_SET_ATTR(MDAS_NAME,  "ord.com",  dbinfo,  status) 
MDAS_INFO_SET_ATTR(MDAS_RSRC_SRVN,  "illustra",  dbinfo,  status) 
MDAS_CONNECT(dbinf o,  NULL,  NULL,  servh,  status) 

MDAS_DISCONNECT(servh,  NULL,  status) 

MDAS_FINALIZE(NULL, status) 

END  PROGRAM 

4.3.7  Interacting  with  MPI 

The  following  example  assumes  that  argv  and  argc  are  system-defined  variables.  The 
handle  MPI_COMM_WORLD  is  defined  by  MPI. 

PROGRAM  do_mpi 

integer  ierr 
MDAS.status  status 

MPI_INIT(ierr) 
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MDAS_INIT(argc,  argv,  MPI_COMM_WORLD ,  status) 
MDAS_FINALIZE(MPI_COMM_WORLD , status) 
MPI_FINALIZE(ierr) 

END  PROGRAM 
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4.4  Mid-Level  Tutorial 


TBD. 
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4.5  Run-Time  Environment 


Intro  . .  .TBD. 

Need  to  discuss  how  MDAS_INIT()  is  involved  with  this  process. 

4.5.1  User  and  Installation  Defined  Parameters 
TBD. 

4.5.2  Default  Parameter  Locations 
TBD. 

4.5.3  Command-Line  Arguments 
TBD. 

4.5.4  Environment  Variables 
TBD. 

4.5.5  “Resource”  Files 
TBD. 

4.5.6  “Ticket”  Files 
TBD. 
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4.6  Language  Bindings 


The  naming  of  MDAS  library  routines  and  data  types  varies  according  to  programming 
language.  This  avoids  ambiguities  in  mixed  language  programs. 

The  MDAS  Library  is  a  functional  rather  than  an  object-oriented  design.  The  MDAS 
Library  may  be  encapsulated  in  C++  application  class  libraries  but  does  not  directly  supply 
a  class  library  interface. 

4.6.1  Library  Calls 

MDAS  Library  call  names  are  implemented  with  the  prefix  mdas*_  where  *  is  F  for  Fortran 
90,  C  for  ANSI  C,  etc.  Thus,  the  routine  MDAS_INIT()  (section  ??)  is  implemented: 

mdasF.init (argc ,  argv,  comm,  status)  (in  Fortran  90) 

mdasC_init(argc,  argv,  comm,  status)  (in  ANSI  C,  C++) 

4.6.2  MDAS  Types 

The  implementation  of  MDAS  data  type  names  (sections  4.7.1,4.8.1,4.11.1)  is  identical  to 
that  of  MDAS  Library  calls.  For  example,  the  base  types  MDAS_string  and  MDAS.status 
are  implemented: 

mdasF.string  (in  Fortran  90) 

mdasF_status 

mdasC_string  (in  ANSI  C,  C++) 

mdasC.status 

4.6.3  MDAS  Tokens 

MDAS  Tokens  are  implemented  as  parameters  in  Fortran  and  pre-processor  macros  in  C 
and  C++.  Name  conflicts  cannot  arise.  They  appear  in  the  language  exactly  as  shown  in 
tables  throughout  this  document. 

The  actual  token  values  in  any  language  are  identical.  However,  values  may  change  across 
library  versions.  Users  are  advised  to  always  use  token  names  instead  of  token  values  for 
portability. 


MDAS  Data  Type 

Fortran  90  Type 

ANSI  C,  C++  Type 

MDAS.byte 

MDAS. character 
MDAS. string 

MDAS. logical 
MDAS. integer 
MDAS. real 

MDAS. double 

MDAS. complex 
MDAS. handle 

character 

character 
character  array 
logical 
integer 
real 

double  precision 

complex 

pointer 

unsigned  char 
char 

char[]  with  ’\0’ 

integer 

long 

float 

double 
double [2] 
void* 

Table  4.1:  MDAS  API  base  data  types  and  their  counterparts  in  standard  languages. 

4.7  Application  Program  Interface 


MDAS  provides  a  High-Level  application  program  interface  (API)  for  simple  interactions 
with  MDAS  metadata  and  services.  It  is  expected  that  most  user  needs  will  be  met  at  this 
level.  Library  writers  and  system  software  developers  may  also  find  the  MDAS  Mid-Level 
architecture  described  in  section  4.8  of  interest. 

This  section  discusses  the  MDAS  High-Level  API  in  detail.  Datatypes  exposed  to  the  user  at 
this  level  are  discussed  in  section  4.7.1.  Function  prototypes  are  presented  in  section  4.7.3. 


4.7.1  API  Data  Types 

The  MDAS  API  defines  several  base  data  types  for  interoperability  with  standard  languages 
types.  A  list  of  currently  supported  types  is  given  in  table  4.1.  MDAS  also  defines  a  set  of 
extended  data  types  discussed  in  detail  below.  Attributes  of  MDAS  extended  data  types 
are  given  in  table  4.2. 

The  implementation  of  these  types  is  language  and  architecture  dependent  (see  section  4.6). 
Type  conversions  between  languages  and  architectures  is  performed  by  Mid-Level  routines 
in  the  MDAS  library. 


4. 7. 1.1  Status 

Most  MDAS  Library  calls  return  a  status  vector  MDAS.status,  which  is  an  integer  array  of 
size  4.  The  use  of  each  element  is  summarized  in  table  4.3. 

status:  (IN/OUT)  MDAS_status 

The  procedures  MDAS.STATUS.MSGO,  MDAS.STATUS.PRINTO ,  and  MDAS. STATUS. INFO  ()  in 
section  4. 7.3.3  provide  an  interface  to  MDAS  status  messages. 
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MDAS  Data  Type 

Fortran  90  Type 

ANSI  C,  C++  Type 

MDAS_status 

MDAS.time 

MDAS_size 

MDAS_spectrum 

comm 

MDAS.token 

MDAS.DATAH 

MDAS.INFOH 

MDAS.SERVH 

integer(4) 
derived  TYPE 
integer(2) 
doubleprecis ion (8) 
MPI  communicator 
integer 
derived  TYPE 
derived  TYPE 
derived  TYPE 

int  [4] 
struct 
long  [2] 
double  [8] 

MPI  communicator 

int 

struct 

struct 

struct 

Table  4.2:  MDAS  API  extended  data  types. 


status  element 

Purpose 

Values 

status (0) 

Flag 

error:  status (0)  <  0 

success:  status  (0)  =0 

warning:  status  (0)  >  0 

status (1) 

Total  errors 

from  0  to  32 

status (2) 

and  warnings 
Codes 

parameterized  bit  codes 

status (3) 

Procedure# 

from  1  to  MDAS_PR0C_C0UNT 

Table  4.3:  The  status  vector.  Bit  codes  are  procedure-specific.  See  procedure  definition 
for  list  of  applicable  bit  codes. 

By  definition,  status (0)  =  0  means  success.  When  status (0)  <  0,  an  error  has  occurred. 
Warnings  are  indicated  by  status(O)  >  0.  The  value  returned  in  status(l)  indicates  the 
total  number  of  errors  and  warnings  which  occurred. 

Array  element  status  (2)  contains  up  to  32  of  status  (bit)  codes  packed  into  a  single  integer 
by  logical  -‘or"  operations.  All  status  codes  have  predefined  exposed  parameter  or  macro 
names  in  the  implementation  language.  (See  the  definition  of  each  call  for  a  list  of  applicable 
status  codes.)  Bit  codes  placed  in  status (2)  may  be  unique  to  the  calling  procedure. 

The  Library  call  procedure  id#  is  returned  in  status (3).  Procedure  id#’s  range  in  value 
from  1  to  MDAS_PROC_COUNT. 

4.7. 1.2  Time 
TBD. 
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MDAS  Handle  Type 

Reference 

comm 

MDAS.DATAH 

MDAS.INFOH 

MDAS.SERVH 

MPI  communicator 
physical  contents  of  a  data  set 
MDAS^info  structure 
service  connection 

Table  4.4:  MDAS  handle  references. 


4,7. 1*3  Size 

TBD. 


4. 7*1. 4  Comm 

Some  versions  of  the  MDAS  Library  are  built  with  MPI  [12]  for  portability  on  parallel 
computing  platforms.  The  MPI  communicator  argument  comm  appears  in  some  MDAS 
Library  routines  to  extend  the  MDAS  interface  to  MPI  programs.  MPI  can  always  be 
suppressed  in  MDAS  Library  routines  by  passing  NULL  for  comm. 


4. 7. 1.5  Handles 

The  MDAS  Library  provides  a  handle  type  for  transparent  interface  to  Info  structures, 
connections,  open  data  sets,  and  other  protocols.  A  list  of  MDAS.handle  types  is  given 
in  table  4.4.  An  MDAS_handle  may  have  an  associated  handle  structure  for  the  purpose 
of  caching  Mid-Level  library  attributes.  The  handle  comm  is  always  address  equivalent  to 
an  MPI  communicator  (or  NULL).  For  more  detail  on  MDAS  handle  structures,  see  sec¬ 
tion  midlevel-handles. 


4.7.2  Info 

A  central  data  type  in  MDAS  is  the  MDAS_info  structure,  commonly  referred  to  as  Info. 
Its  primary  use  is  the  capture  and  specification  of  metadata  from/to  the  MDAS  API.  More 
specifically.  Info  structures  are  used  to  specify  information  about 


•  entities 

•  entity  attributes 

•  entity  auxilary  data 

Info  structures  are  opaque  to  the  calling  language  and  managed  by  a  set  of  API  functions. 
Implementations  of  Info  structures  are  language  dependent. 
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4.7. 2.1  Info  Semantics 


The  MDAS  Info  structure  provides  a  means  for  users  to  supply  un-ordered,  incomplete 
metadata  to  the  MDAS  Library  for  correlation  with  complete  metadata  sets  stored  in  an 
MDAS  Catalog.  This  section  discusses  the  semantic  interpretation  of  user-supplied  Info  in 
the  context  of  MDAS  Library  requests. 

Complete  metadata  specifications  are  dense  with  information  which  is  (a)  necessary  for 
arbitrary  system  transactions  and  (b)  typically  unknown  by  end-users.  As  such,  the  MDAS 
Library  provides  information  discovery.  A  library  interface  for  this  purpose  must  provide  a 
means  for 

1.  users  to  easily  specify  what  they  know 

2.  users  and  the  library  to  easily  extract  what  they  need  to  know 

3.  the  library  to  efficiently  store  partial  and  full  metadata  information 

4.  the  library  to  translate  partial  information  into  Catalog  queries 

Further,  system-level  metadata  is  inherently  heirarchical.  For  example,  data  sets  have 
attributes  of  names,  summary  information,  storage  information,  etc.  For  example,  storage 
attributes  (in  a  distributed  system  )  of  a  data  set  must  indicate  the  number  of  logical  storage 
replications.  Each  storage  replication  may  have  attribute  of  being  partitioned,  in  which 
case  each  attributes  of  the  segment  storage  (e.g.,  location,  segmenting  method)  must  be 
maintained.  Historically,  users  tracked  such  information  in  a  log  book.  Part  of  the  MDAS 
design  is  to  track  these  details  for  the  user. 

The  approach  to  these  problems  in  MDAS  is  to  allow  users  to  specify  “what  they  know” 
about  an  entity  with  a  sequential  protocol;  i.e.,  a  list  of  known  attributes  of  the  entity. 
Thus,  the  creation  of  Info  structures  is  always  in  the  context  of  an  entity.  Any  additional 
records  added  to  the  structure  are  then  taken  to  be  attributes  or  auxilary  data  of  the  entity. 
In  particular,  users  should  be  able  to  specify  very  little  about  an  entity  let  MDAS  determine 
the  remaining  system  level  details  required  to  carry  out  their  transaction. 

For  example,  suppose  a  user  knows  the  name  of  a  particular  data  set  and  that  it  is  the 
member  of  some  group  defined  in  the  MDAS  Catalog.  To  create  Info  about  these  attributes 
of  the  data  set,  a  user  program  executes  a  command  to 

“create  an  Info  structure  of  entity  type  MDAS.DATASET.” 

To  add  attributes  containing  the  data  set  name  and  group,  a  user  program  follows  the  Info 
creation  instruction  with 


“set  an  Info  attribute  containing  name”  and 
“set  an  Info  attribute  containing  group.” 
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In  this  manner,  the  user  is  provided  with  a  simple,  sequential  interface  for  data  entry 
and  the  library  can  take  care  of  the  details  of  laying  the  data  out  in  nested  hierarchies  of 
(incomplete)  metadata.  This  meets  goal  #1. 

Goal  #2  is  to  provide  users  and  internal  MDAS  library  procedures  with  a  straightforward 
method  of  reading  values  from  an  Info  structure.  For  example:  suppose  that  a  query  to  an 
MDAS  Catalog  has  returned  a  fully  populated  Info  structure  containing  metadata  about 
a  particular  data  set  and  a  user  desires  to  extract  metadata  attributes  of  the  data  set  into 
the  memory  of  a  user  program. 

Three  things  are  required  to  achieve  this  functionality:  (a)  the  user  presumably  knew  that 
MDAS  maintains  such  information,  (b)  the  user  must  determine  what  names  or  function 
in  MDAS  can  be  used  to  specify  the  attribute  of  interest  to  the  MDAS  Library,  and  (c) 
the  library  must  define  a  protocol  for  returning  attribute  information  to  the  user.  In  order 
to  obtain  goal  #1,  MDAS  adopted  the  semantics  of  building  Info  structures  by  adding 
attributes  to  entities.  Thus,  users  will  have  the  expectation  of  extracting  Info  values  in  a 
like  manner.  To  support  this  expectation,  MDAS  provides  a  “seek  and  read''  protocol  based 
on  the  same  attribute  names  that  users  provide  to  input  entity  attributes.  For  example, 
to  obtain  the  common  name  of  a  data  set  from  a  “Catalog  populated”  Info  structure  into 
program  variable  A,  the  user  would 

“scan  the  value  for  attribute  MDAS. NAME  of  the  MDAS.DATASET  entity  into  A.” 

Goal  #3  (efficient  in-memorv  store  of  metadata)  could  be  achieved  by  ignoring  #1  and 
#2  and  implementing  Info  structures  as  a  C  struct  with  no  interface  to  the  members 
other  than  direct  naming  of  the  structure  members.  This  would  not  only  degrade  the  user 
interface,  but  expose  the  underlying  structure  to  direct  user  manipulation  and  place  the 
Library  at  risk.  At  the  same  time,  it  is  prudent  to  implement  Info  structures  as  C1  or  F90 
structures — but  with  private  members  served  only  to  the  user  by  the  interface  described  for 
#1  and  #2.  Note  that  this  approach  permits  long-term  evolutions  in  the  Info  structure 
design  without  sacrificing  the  portability  of  early  implementations.  Further,  it  allows  the 
internal  representation  of  an  Info  structure  to  be  “flattened  out”  and  reduce  the  number 
of  dereferences  required  to  extract  a  given  value.  Thus,  the  complexity  of  the  internal  Info 
structure  can  increase  for  the  benefit  of  efficiency  without  sacrificing  the  simplicity  of  the 
user  interface. 

To  achieve  “ease  of  translation”  of  data  in  Info  format  to  Catalog  queries  (goal  #4),  the 
MDAS  Library  incrementally  caches  SQL-like  structures  in  Info  based  on  the  entity  type 
and  attributes.  A  convenience  routine  is  then  provided  to  convert  partial  entity  descriptions 
in  Info  structures  to  SQL.  An  alternate  approach  would  be  to  ask  the  end  user  to  use  SQL 
directly.  It  is  expected  that  this  would  be  too  great  a  burden  on  most  users.  It  also  would 
make  Catalog  design  changes  difficult  to  implement  transparently.  However,  for  those  users 
that  need  a  SQL  interface  MDAS  provides  a  SQL  Exec  function.  A  table  of  entity  attributes 
and  their  associated  tables  for  the  current  implementation  are  given  in  the  MDAS  User 
Guide. 
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4. 7. 2. 2  Base  Entities 


4.7.2. 2.1  MDAS-DATASET 


MDAS-DATASET  attribute 

Type 

Use 

(Base) 

MDAS.NAME 

MDAS_string 

Name  of  data  set.  When  specified  in  the  info  argument 
of  MDASJNQUIREQ,  matches  to  data  sets  with  this 
name  or  alias  will  be  sought.  When  scanning  this 
attribute  from  an  Info  structure  that  resulted  from  an 
inquiry,  the  “common”  name  of  the  data  set  will  be 
returned.  A  name  may  only  be  registered  once.  Any 
further  name  registrations  will  produce  a  new  alias. 

MDASJD 

MDAS-integer 

Catalog  id#.  Can  be  used  in  inquiries  or  scanned  from 
inquiry  results.  Value  is  never  set  by  user. 

MDAS.CDJD 

MDAS-integer 

Id#  of  MDAS  Catalog  in  which  this  data  set  can  be 
found.  Can  be  used  in  inquiries  or  scanned  from 
inquiry  results.  MDAS  uses  this  value  to  differentiate 
between  multiple  catalogs  referenced  during  a  single 
run-time.  Value  is  set  by  library  and  is  only  valid 
during  run-time. 

MDAS-DATASET  attribute 

Type 

Use 

(Version) 

MDAS.VERSION 

MDAS -string 

MDAS  Version  #  of  data  set.  When  the  “version”  of  a 
data  set  is  updated,  it  keeps  the  same  names  and  alias’ 
but  obtains  a  new  Catalog  id#.  Creating  a  new 
“version”  of  a  data  set  is  synonymous  with  re-writing 
the  data  set  with  new  or  different  content.  If  the 
content  is  unchanged  but  in  a  different  format  or 
storage  medium,  MDAS  considers  this  a  replication. 

See  MDAS-STOR.FMTN  and  MDAS.REPLICATES 
for  comparison. 

M  D  AS  -V  E  RSIO  NX 

MDASJogical 

Indicates  whether  MDAS.VERSIONM  is  an  external 
method  registered  in  the  MDAS  Catalog  or  an  internal 
MDAS  Library  method.  If  external, 

MDASJVERSiONX  evaluates  to  “true”. 

MDAS.VERSIONM 

MDAS-integer 

Depending  upon  the  value  of  MDAS.VERSIONX, 
MDAS.VERSIONM  is  either  the  Catalog  id#  of  an 
MDAS.METHOD  or  an  MDAS  Library  token  for  an 
internal  method.  See  table  ??  for  a  list  of  applicable 
tokens. 

MDAS.VERSIONP 

MDAS_integer 

Catalog  id#  of  previous  version  (if  any)  of  this  data 
set.  This  is  useful  for  automatically  propagating  new 
alias’  to  previous  versions. 

M  DAS  _V  E  RSIO  N  N 

MDAS  integer 

Catalog  id#  of  next  version  (if  any)  of  this  data  set. 

This  is  particularly  useful  for  automatically 
propagating  new  alias’  to  later  versions. 
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MDAS.DATASET  attribute 

Type 

Use 

(Alias) 

MDAS-ALIAS 

MDASjstring 

Alternate  names  for  the  data  set.  On  input  to 

MDAS  JNQUIRE0,  this  is  functionally  equivalent  to 
MDAS.NAME.  When  scanning  this  attribute  from  an 
Info  structure  that  resulted  from  an  inquiry,  an 
element  of  the  MDAS_ALIASV  array  will  be  returned. 
When  preparing  an  MDAS.DATASET  Info  structure 
for  registration,  adding  this  attribute  will  also  add  an 
element  to  the  MDAS.ALIASV  array. 

MDAS_ALIASC 

MDAS_integer 

#  of  strings  in  MDAS.ALIASV. 

MDAS_ALIASV 

MDAS_string 

array 

Array  of  alias  strings.  To  read  this  attribute,  first  read 
MDAS—A.LIASC  and  allocate  an  array  of  that  size. 
Alternately,  incrementally  read  MDAS_ALIAS.  To  set 
this  attribute,  first  set  MDAS.ALIASC  or  set 
MDAS-ALIAS  incrementally. 

MDAS.DATASET  attribute 

Type 

Use 

( Documentation ) 

MDAS.ABSTRACT 

MDASJnteger 

Catalog  id#  of  Abstract.  Every  abstract  is  an 
independent  entity.  To  add  an  abstract,  first  register 
the  abstract  and  obtain  its  Catalog  id#. 

MDAS-DOC 

MDAS  Jnteger 

Catalog  id#  of  Documentation.  Every  set  of 
documentation  is  an  independent  entity.  To  add 
documentation,  first  register  the  doc’s  and  obtain  their 
Catalog  id#. 
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MDAS.DATASET  attribute 

Type 

Use 

(SD) 

MDAS.SD-TABLE 

M  DAS  .integer 

Catalog  id#  of  relational  table  which  contains  this 
data  set  (and  possibly  others)  as  a  LOB  in  a  column 
cell.  To  add  this  attribute,  first  register  the  table  as  an 
MDAS.DATASET  and  then  obtain  the  Catalog  id#. 
Note:  To  register  a  data  set  with  SD  attributes,  all 

SD  attributes  must  be  specified. 

MDAS.SD.KEYC 

MDAS-integer 

#  of  relational  columns  in  MDAS_SD_TABLE 
applicable  to  MDAS  inquiries.  Identifies  the  #  of 
elements  in  MDASJSD.COLS,  MDASJSD-KEY-TYP, 
and  MDAS.SD-KEY. 

MDAS_SD_COLS 

MDAS  .string 
array 

The  names  of  columns  in  MDAS_SD_TABLE  applicable 
to  MDAS  inquiries.  To  read  this  attribute,  first  read 
MDAS_SD_KEYC  and  allocate  an  array  of  that  size. 

To  set  this  attribute,  first  set  MDAS-SD-KEYC. 

MDAS_SD_KEY_TYP 

MDAS -integer 

The  (MDAS)  data  types  of  the  columns  named  in 
MDAS-SD-COLS. 

MDASJSD.KEYS 

MDAS_handle 

The  values  in  the  columns  of  MDAS-SD-TABLE  which 
uniquely  identify  this  data  set.  To  read  this  attribute, 
first  read  MDAS-SD-KEYC  and 

MDAS-SD.KEY-TYP,  then  allocate  an  appropriate 
structure  or  array.  To  set  this  attribute,  first  set 
MDAS_SD_KEYC,  MDAS_SD-COLS,  and 

M  DAS  _SD  .KEYS. 

MDASJSD-LOB.COL 

MDAS_string 

Name  of  SD  column  cell  containing  LOB  for  this  data 
set. 

32 


MDAS-DATASET  attribute 

Type 

Use 

(Logical  Group) 

MDAS_STOR_GRPN 

M  DAS  jst  ring 

Name  of  some  MDAS-GROUP  in  which  this  data  set 
has  membership.  When  specified  in  the  info  argument 
of  MDAS  JNQUIRE0,  matches  to  data  sets  with  this 
group  will  be  sought.  When  scanning  this  attribute 
from  an  Info  structure  that  resulted  from  an  inquiry, 
an  element  of  the  MDAS-STOR-GRPNV  array  will  be 
returned.  When  preparing  an  MDAS-DATASET  Info 
structure  for  registration,  adding  this  attribute  will  also 
add  an  element  to  the  MDAS_STOR_GRPNV  array. 

MDAS_STOR_GRPI 

MDASJnteger 

Catalog  id#  of  some  MDAS-GROUP  in  which  this 
data  set  has  membership.  When  specified  in  the  info 
argument  of  MDAS_INQUIRE(),  matches  to  data  sets 
with  this  group  will  be  sought.  When  scanning  this 
attribute  from  an  Info  structure  that  resulted  from  an 
inquiry,  an  element  of  the  MDAS_STOR_GRPIV  array 
will  be  returned.  When  preparing  an 

MDAS-DATASET  Info  structure  for  registration, 
adding  this  attribute  will  also  add  an  element  to  the 
MDAS_STOR_GRPIV  array. 

MDAS.STOR.GRPNC 

MDASJnteger 

#  of  MDAS  .GROUP  names  in  MDAS.STOR-GRPNV 
array. 

MDASJSTOR.GRPNV 

MDAS_string 

array 

Array  of  MDAS-GROUP  names  in  which  this  data  set 
has  membership.  MDAS_STOR_GRPNV  is  the  union 
of  group  memberships  across  any  replicates  of  the  data 
set.  A  group  membership  need  not  span  all  replicates. 

To  read  this  attribute,  first  read 

MDAS_STOR_GRPNC  and  allocate  an  array  of  that 
size.  Alternately,  incrementally  read 
MDAS-STOR-GRPN.  To  set  this  attribute,  first  set 
MDAS-STOR.GRPNC  or  set  MDAS.STOR.GRPN 
incrementally. 

MDAS-STOR_GRPIC 

MDASJnteger 

#  of  MDAS-GROUP  Catalog  id#s  in 
MDAS.STOR.GRPIV  array. 

MDAS-STOR.GRPIV 

MDASJnteger 

array 

Array  of  MDAS-GROUP  Catalog  id#'s  in  which  this 
data  set  has  membership.  MDAS_STOR_GRPIV  is  the 
union  of  group  memberships  across  any  replicates  of 
the  data  set.  A  group  membership  need  not  span  all 
replicates.  To  read  this  attribute,  first  read 
MDAS_STOR_GRPIC  and  allocate  an  array  of  that 
size.  Alternately,  incrementally  read 

MDAS-STOR-GRPI.  To  set  this  attribute,  first  set 
MDAS-STOR.GRPIC  or  set  MDAS.STOR-GRPI 
incrementally. 
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M  DAS  .DATASET  attribute 

Type 

Use 

(Logical  Domain) 

MDAS-STOR.DMNN 

MDAS_string 

Name  of  some  MDAS-DOMAIN  in  which  this  data  set 
has  membership.  When  specified  in  the  info  argument 
of  MDAS  JNQUIREQ,  matches  to  data  sets  with  this 
domain  will  be  sought.  When  scanning  this  attribute 
from  an  Info  structure  that  resulted  from  an  inquiry, 
an  element  of  the  MDAS-STOR-DMNNV  array  will  be 
returned.  When  preparing  an  MDAS.DATASET  Info 
structure  for  registration,  adding  this  attribute  will  also 
add  an  element  to  the  MDAS_STOR_DMNNV  array. 

MDAS-STOR.DMNI 

MDASinteger 

Catalog  id#  of  some  MDAS-DOMAIN  in  which  this 
data  set  has  membership.  When  specified  in  the  info 
argument  of  MDAS.INQUIREQ,  matches  to  data  sets 
with  this  domain  will  be  sought.  When  scanning  this 
attribute  from  an  Info  structure  that  resulted  from  an 
inquiry,  an  element  of  the  MDAS_STOR_DMNIV  array 
will  be  returned.  When  preparing  an 

MDAS-DATASET  Info  structure  for  registration, 
adding  this  attribute  will  also  add  an  element  to  the 
MDAS-STOR-DMNIV  array. 

MDAS.STOR-DMNNC 

M  DAS  integer 

#  of  MDAS-DOMAIN  names  in 

MDAS-STOR-DMNNV  array. 

MDAS-STOR-DMNNV 

M  DAS  .string 
array 

Array  of  MDAS_DOMAIN  names  in  which  this  data 
set  has  membership.  MDAS_STOR_DMNNV  is  the 
union  of  domain  memberships  across  any  replicates  of 
the  data  set.  A  domain  membership  need  not  span  all 
replicates.  See  MDAS_REPL_DMNNA.  To  read  this 
attribute,  first  read  MDAS_STOR_DMNNC  and 
allocate  an  array  of  that  size.  Alternately, 
incrementally  read  MDAS-STOR.DMNN.  To  set  this 
attribute,  first  set  MDAS-STOR.DMNNC  or  set 

M  DAS  _ST  O  R-D  M  N  N  increment  ally. 
MDAS-STOR-DMNNV  contains  all  names  in 
i  M D AS-REP L -DM N N A . 

MDAS-STOR-DMNIC 

MDAS_integer 

#  of  MDAS-DOMAIN  Catalog  id#s  in 
MDAS-STOR_DMNIV  array. 

MDAS.STOR.DMNIV 

MDASJnteger 

array 

Array  of  MDAS-DOMAIN  Catalog  id#'s  in  which  this 
data  set  has  membership.  MDAS_STOR_DMNIV  is 
the  union  of  domain  memberships  across  any  replicates 
of  the  data  set.  A  domain  membership  need  not  span 
all  replicates.  See  MDAS_REPL_DMNIA.  To  read  this 
attribute,  first  read  MDAS_STOR_DMNIC  and 
allocate  an  array  of  that  size.  Alternately, 
incrementally  read  MDAS_STOR_DMNI.  To  set  this 
attribute,  first  set  MDAS_STOR_DMNIC  or  set 
MDAS_STOR_DMNI  incrementally. 
MDAS_STOR_DMNIV  contains  all  names  in 
MDAS-REPL-DMNIA. 
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MDAS.DATASET  attribute 

Type 

Use 

(Input  Lineage) 
MDAS.STORJN 

MDASJnteger 

Catalog  id#  of  an  M DAS _D ATA SET  source  used  in 
the  creation  of  this  data  set  (if  any).  Applies  only  to 
the  origination  of  data  set,  not  replications  or 
segments.  When  inquiring  about  data  sets, 
MDAS.STORJN  may  be  used  to  match  source 
“lineage”.  When  scanning  MDAS.STORJN  from  Info 
returned  by  MDAS JNQUIREQ,  the  value  is  some 
element  of  MDAS.STORJNV.  When  adding  attributes 
to  an  Info  structure  for  Catalog  registration,  set 
MDASJSTORJNC  and  use  MDAS.STORJNV. 

MDAS.STORJNC 

MDAS_integer 

#  of  items  listed  in  MDAS.STORJNV.  When 
inquiring  about  data  sets,  MDAS.STORJNC  may  be 
used  to  match  the  count  of  data  sets  in  source 
“lineage”.  When  scanning  MDAS.STORJNC  from 
data  set  Info  returned  by  MDAS  JNQUIREQ,  the 
value  is  the  actual  count  for  a  particular  data  set. 

When  adding  attributes  to  an  Info  structure  for 

Catalog  registration,  set  MDAS.STORJNC  before 
making  incremental  adds  of  MDAS.STORJN  or 
adding  the  MDAS.STORJNV  vector. 

MDAS.STORJNV 

MDASJnteger 

array 

Array  of  Catalog  an  MDAS.DATASET  id#’s  that 
specify  the  sources  used  to  create  this  data  set. 

Applies  only  to  the  origination  of  data  set,  not 
replications  or  segments.  The  ordering  of  inputs 
specified  in  MDAS.STORJNV  must  match  the 
ordering  of  inputs  defined  in  the  Catalog  metadata  for 
MDAS.STOR.GEN. 

MDAS.DATASET  attribute 

Type 

Use 

(Consequential  Lineage) 

MDAS.STOR.OUT 

MDASJnteger 

Catalog  id#  of  an  entity  produced  from  this  data  set. 
When  inquiring  about  data  sets,  MDAS.STOR.OUT 
may  be  used  to  match  output  “lineage”.  When 
scanning  MDAS.STOR.OUT  from  Info  returned  by 
MDAS  JNQUIREQ,  the  value  returned  is  some 
element  of  MDAS.STOR.OUTV.  When  adding 
attributes  to  an  Info  structure  for  Catalog  registration, 
incremental  addition  of  the  MDAS.STOR.OUT 
attribute  will  add  elements  to  MDAS.STOR.OLTTV 
and  may  increment  MDAS.STOR.OUTC  if  necessary. 

To  avoid  ambiguous  behavior,  scan  or  set 
MDAS.STOR.OUTC  and  use  MDAS.STOR.OUTV. 

M  D  AS.STO  R.O  UTC 

MDASJnteger 

#  of  items  listed  in  MDAS.STOR.OUTV7. 

MDAS.STOR.OUTV 

MDASJnteger 

Array  of  Catalog  id#5s  of  entities  created  from  this 

array 

data  set.  Applies  only  to  the  logical  data  set,  not 
replicates  or  segments. 
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MDAS-DATASET  attribute 

Type 

Use 

(Generation  Lineage) 

Catalog  id#  of  the  MDAS.METHOD  which  generated 
this  data  set.  When  inquiring  about  data  sets, 
MDAS_STOR_GEN  may  be  used  to  match  method 
“lineage”.  When  scanning  MDAS_STOR_GEN  from 
data  set  Info  returned  by  MDAS-INQUIREQ,  the 
value  returned  is  the  method  which  generated  the  data 
set.  The  ordering  of  inputs  specified  in 
MDAS_STOR_INV  must  match  the  ordering  of  inputs 
defined  in  the  Catalog  metadata  for 

MDAS_STOR_GEN.  Applies  only  to  the  origination  of 
data  set,  not  replications  or  segments. 

MDAS.STOR-GEN 

MDASJnteger 

MDASJSTOR-GNP 

M  DAS  .string 

The  parameter  list  (if  any)  used  with 
MDAS-STOR-GEN  to  generate  this  data  set.  When 
inquiring  about  data  sets,  MDAS_STOR_GNP  may  be 
used  to  match  method  “lineage” .  When  scanning 
MDAS-STOR-GNP  from  data  set  Info  returned  by 
MDASJNQUIREQ,  the  value  returned  is  the 
parameter  list  used  to  generate  the  data  set.  Applies 
only  to  the  origination  of  data  set,  not  replications  or 
segments.  The  format  of  MDAS_STOR_GNP  must 
match  the  parameter  format  required  for 
MDAS-STOR-GEN. 

MDAS_STOR_GNR 

M  DAS -integer 

Catalog  id#  of  the  MDAS.RESOURCE  on  which 
MDAS_STOR_GEN  executed  to  create  the  data  set. 
When  inquiring  about  data  sets,  MDAS_STOR_GNR 
may  be  used  to  match  method  “lineage”.  Applies  only 
to  the  origination  of  data  set,  not  replications  or 
segments. 

M  D  AS  _STO  R_GN  U 

MDASJnteger 

Catalog  id#  of  the  MDASJJSER  which  executed 
MDAS_STOR_GEN  to  create  the  data  set.  When 
inquiring  about  data  sets,  MDAS_STOR_GNU  may  be 
used  to  match  method  “lineage".  Applies  only  to  the 
origination  of  data  set,  not  replications  or  segments. 

MDAS.DATASET  attribute 

Type 

Use 

(Re-Generation  Policy) 
MDAS-STOR-PLCY 

MDASJnteger 

Update  policy  for  this  data  set.  When  inquiring  about 
data  sets,  MDAS_STOR_PLCY  may  be  used  to  match 
the  policy  of  an  arbitrary  data  set.  When  scanning 
MDAS_STOR_PLCY  from  data  set  Info  returned  by 
MDAS  JNQUIRE(),  the  value  represents  the  data  set 
update  policy.  When  adding  attributes  to  an  Info 
structure  for  Catalog  registration,  only  one 
MDAS-STOR-PLCY  may  be  set. 
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MDASJDATASET  attribute 

Type 

Use 

(Trigger) 

MDAS.STOR.TRGM 

MDAS  integer 

Catalog  MDAS.METHOD  id#  of  some  trigger  for  this 
data  set.  These  methods  are  executed  when  updates 
are  made  to  this  data  set  and  the  corresponding  trigger 
policy  evaluates  to  “true”.  When  inquiring  about  data 
sets,  MDAS_STOR_TRGM  may  be  used  to  match  data 
set  triggers.  When  scanning  MDAS_STOR_TRGM 
from  data  set  Info  returned  by  MDASJNQUIREQ,  the 
value  returned  is  some  element  of 
MDAS_STOR_TRGMV.  When  adding  attributes  to  an 
Info  structure  for  Catalog  registration,  incremental 
addition  of  the  MDAS_STOR_TRGM  attribute  will 
add  elements  to  MDASJSTOR.TRGMV  and  may 
increment  MDAS.STOR.TRGC  if  necessary.  To  avoid 
ambiguous  behavior,  scan  or  set  MDAS.STOR.TRGC 
and  use  MDAS-STOR.TRGM V. 

MDAS_STOR_TRGP 

M  DAS  integer 

Catalog  MDAS.POLICY  id#  of  some  trigger  policy  for 
this  data  set.  Triggers  are  executed  when  updates  are 
made  to  this  data  set  and  the  corresponding  trigger 
policy  evaluates  to  “true”.  When  inquiring  about  data 
sets,  MDAS.STOR.TRGP  may  be  used  to  match  data 
set  policies.  When  scanning  MDAS.STOR_TRGP  from 
data  set  Info  returned  by  MDAS_INQUIRE(),  the 
value  returned  is  some  element  of 

MDAS.STOR.TRGPV.  When  adding  attributes  to  an 
Info  structure  for  Catalog  registration,  incremental 
addition  of  the  MDAS.STOR.TRGP  attribute  will  add 
elements  to  MDAS.STOR.TRGPV  and  may  increment 
MDAS.STOR_TRGC  if  necessary.  To  avoid  ambiguous 
behavior,  scan  or  set  MDAS.STOR.TRGC  and  use 

M  D  AS.ST  O  R.TRG  P  V . 

MDAS_STOR_TRGC 

M  D  AS  int  eger 

#  of  triggers  and  trigger  policies  listed  in 
MDASJSTOR.TRGMV  and  MDAS.STOR.TRGPV. 

MDASJSTOR.TRGMV 

MDASinteger 

array 

Array  of  method  Catalog  id#7s.  These  methods  are 
executed  when  updates  are  made  to  this  data  set  and 
the  corresponding  policy  in  MDAS.STOR.TRGPV' 
evaluates  to  “true”. 

MDAS.STOR.TRGPV 

MDASinteger 

array 

Array  of  policy  Catalog  id#'s  for  triggers  in 
MDAS.STOR.TRGMV. 

MDAS.DATASET  attribute 

Type 

Use 

(Storage  Date) 

MDAS.STOR.DATE 

M  DAS  .time 

Creation  date  of  data  set.  It  is  typically  scanned  or 
specified  with  MDAS.INFO_SCAN.ATTR(info, 
MDAS.STOR.DATE,  odate,  status)  and 
MDASJNFO_SET_ATTR(MDAS-STOR_DATE, 

odate,  info,  status).  If  the  data  set  has  been  replicated, 
MDAS.STOR.DATE  is  also  the  creation  date  of  the 
“original”  replicate.  See  MDAS.REPL.DATE  and 
MDAS.REPL.DATEV. 
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MDAS.DATASET  attribute 

Type 

Use 

(Storage  Permanence) 

MDAS-STORJPERM 

MDAS_double 

Probability  of  not  being  purged  (permanence). 
MDAS_STOR_PERM  applies  to  all  instances  of  the 
data  set.  If  the  data  set  has  been  replicated, 
MDAS.STOR.PERM  represents  the  cumulative 
probability  across  all  replications  (all  elements  of 
MDAS_REPL_PERMV).  See  MDAS.REPLICATES. 

MDAS-STOR.PURG 

MDASJogical 

True  if  data  set  has  been  purged. 

MDAS.STOR.PURG  applies  to  all  instances  of  the 
data  set.  If  the  data  set  has  been  replicated, 
MDAS_STOR_PURG  represents  the  conjunctive  truth 
across  all  replications  (all  elements  of 
MDAS_REPL_PURGV).  See  M  DAS  .REPLICATES. 

MDAS.DATASET  attribute 

Type 

Use 

(Storage  Size) 

MDAS.STOR.SIZE 

MDAS  .size 

i 

The  size  of  the  data  set,  in  bytes.  When  inquiring 
about  data  sets,  MDAS.STOR.SIZE  may  be  used  to 
match  the  size  of  an  arbitrary  data  set  or  data  set 
replicate  (see  MDAS .REPLICATES  below).  When 
scanning  MDAS.STOR.SIZE  from  Info  returned  by 
MDAS  JNQUIREQ,  the  value  may  represent  either  (a) 
the  size  of  an  unreplicated  data  set  or  (b)  the  size  of 
some  replicate  of  the  data  set  (an  element  of 
MDAS.REPL.SIZEV).  When  adding  attributes  to  an 
Info  structure  for  Catalog  registration,  use 
MDAS.REPL.SIZE  with 

MDAS  JNFO_SET_RATTR(). 
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MDAS-DATASET  attribute 

Type 

Use 

(Storage  Format) 

M  D  AS  _ST  O  R_F  MTN 

MDASjstring 

The  name  (or  alias)  of  the  data  set  format.  When 
inquiring  about  data  sets,  MDAS-STOR-FMTN  may 
be  used  to  match  the  format  of  an  arbitrary  data  set  or 
data  set  replicate  (see  MDAS.REPLICATES  below). 
When  scanning  MDAS_STOR_FMTN  from  Info 
returned  by  MDAS  JNQUIREQ,  the  name  may 
represent  either  (a)  the  format  of  an  unreplicated  data 
set  or  (b)  the  format  of  some  replicate  of  the  data  set 
(an  element  of  MDAS_REPL_FMTNV).  When  adding 
attributes  to  an  Info  structure  for  Catalog  registration, 
use  MDAS_REPL_FMTN  with 
MDASJNFO.SET.RATTR()  and 
MDASJNFO_SCAN_RATTR(). 

MDAS_STOR_FMTI 

MDAS_integer 

The  Catalog  id#  of  the  data  set  format.  When 
inquiring  about  data  sets,  MDAS-STOR-FMTI  may  be 
used  to  match  the  format  of  an  arbitrary  data  set  or 
data  set  replicate  (see  MDAS.REPLICATES  below). 
When  scanning  MDAS_STOR_FMTI  from  Info 
returned  by  MDASJNQUIREQ,  the  value  may 
represent  either  (a)  the  format  of  an  unreplicated  data 
set  or  (b)  the  format  of  some  replicate  of  the  data  set 
(an  element  of  MDAS-REPL.FMTIV).  When  adding 
attributes  to  an  Info  structure  for  Catalog  registration, 
use  MDAS -REP L_FMTI  with 
MDASJNFO-SET-RATTRQ  and 
MDASJNFO_SCAN_RATTR(). 
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MDAS. DATASET  attribute 

Type 

Use 

(Storage  Resource) 

The  name  (or  alias)  of  a  storage  resource  for  the  data 
set.  When  inquiring  about  data  sets, 
MDAS_STOR-RSCN  may  be  used  to  match  the  name 
of  an  arbitrary  storage  resource.  When  scanning 
MDAS-STOR_RSCN  from  Info  returned  by 
MDASJNQUIRE0,  the  name  may  represent  either  (a) 
the  storage  resource  of  an  unreplicated  data  set  or  (b) 
the  storage  resource  of  some  replicate  of  the  data  set 
(an  element  of  MDASJREPL.RSCNV).  When  adding 
attributes  to  an  Info  structure  for  Catalog  registration, 
use  MDAS_REPL_RSCN  with 
MDASJNFO-SET_RATTR(). 

MDAS-STOR-RSCN 

M  DAS  .string 

MDAS.STOR.RSCI 

MDASJnteger 

The  Catalog  id#  of  a  storage  resource  for  the  data  set 
format.  When  inquiring  about  data  sets, 
MDAS_STOR_RSCI  may  be  used  to  match  the  id#  of 
an  arbitrary  storage  resource.  When  scanning 
MDAS-STOR-RSCI  from  Info  returned  by 
MDAS-INQUIREQ,  the  value  may  represent  either  (a) 
the  id#  of  a  storage  resource  for  an  unreplicated  data 
set  or  (b)  the  id#  of  a  storage  resource  for  some 
replicate  of  the  data  set  (an  element  of 
MDAS_REPL_RSCIV).  When  adding  attributes  to  an 
Info  structure  for  Catalog  registration,  use 
MDAS-REPL-RSCI  with 

MDAS_INFO_SET_RATTR(). 

M DAS -DATASET  attribute 

Type 

Use 

(Storage  Server) 

M  D  AS  _ST  0  R_S  RV  N 

MDAS_string 

The  name  (or  alias)  of  a  software  server  for  the  data 
set.  This  might  be  the  O/S  for  the  storage  resource,  or 
a  specialized  service  provider.  When  inquiring  about 
data  sets,  MDAS-STOR_SRVN  may  be  used  to  match 
the  name  of  an  arbitrary  software  server.  When 
scanning  MDAS_STOR_SRVN  from  Info  returned  by 
MDASJNQUIREQ,  the  name  may  represent  either  (a) 
the  software  server  for  an  unreplicated  data  set  or  (b) 
the  software  server  for  some  replicate  of  the  data  set 
(an  element  of  MDAS_REPL_SRVNV).  When  adding 
attributes  to  an  Info  structure  for  Catalog  registration, 
use  M DAS _REP L _S RV N  with 
MDASJNFO_SETJRATTR(). 

MDAS-STOR-SRVI 

MDASJnteger 

The  Catalog  id#  of  a  software  server  for  the  data  set 
format.  This  might  be  the  O/S  for  the  storage 
resource,  or  a  specialized  service  provider.  When 
inquiring  about  data  sets,  MDAS_STOR_SRVI  may  be 
used  to  match  the  id#  of  an  arbitrary  software  server. 
When  scanning  MDAS_STOR_SRVI  from  Info  returned 
by  MDAS_INQUIRE(),  the  value  may  represent  either 
(a)  the  id#  of  a  software  server  for  an  unreplicated 
data  set  or  (b)  the  id#  of  a  software  server  for  some 
replicate  of  the  data  set  (an  element  of 
MDAS-REPL_SRVIV).  When  adding  attributes  to  an 
Info  structure  for  Catalog  registration,  use 

MDAS -REPLJSRVI  with 

MDASJNFO_SET_RATTR(). 

41 


MPAS -DATASET  attribute  Type _ 

(Storage  Path  and  Name) 

MDAS_STOR_DIR  MDAS-string 


Use 


The  storage  "‘directory”  of  the  data  set  on  the  given 
resource  (MDAS.STOR.RSCN  or 
MDAS_STOR_RSCI)  and  server  (MDAS.STOR.SRVN 
or  MDAS-STOR-SRVI).  MDAS  distinguishes  between 
data  set  storage  directories  and  storage  names .  In  the 
simple  Unix  or  MS  DOS  case,  the  full  file  path  is  the 
concatenation  of  MDAS_STOR_NAM  to 
MDAS_STOR_DIR.  When  inquiring  about  data  sets, 
MDAS.STOR-DIR  may  be  used  to  match  the 
directory  of  an  arbitrary  data  set  or  data  set  replicate 
(see  MDAS-REPLICATES  below).  When  scanning 
MDAS-STOR.DIR  from  Info  returned  by 
MDASJNQUIREQ,  the  value  may  represent  either  (a) 
the  directory  of  an  unreplicated  data  set  or  (b)  the 
directory  of  some  replicate  of  the  data  set  (an  element 
of  MDAS _REP L-DIRV).  When  adding  attributes  to  an 
Info  structure  for  Catalog  registration,  use 
MDAS-REPL-DIR  with  MDAS_INFO_SET_RATTR(). 


MDAS-STOR-NAM 


MDAS-string 


The  O/S  or  server  name  of  the  data  set  at  the  given 
directory  (MDAS_STOR_DIR)  on  the  given  resource 
(MDAslSTOR.RSCN  or  MDAS.STOR-RSCI)  and 
server  (MDAS_STOR_SRVN  or  MDAS-STOR-SRVI). 
MDAS  distinguishes  between  data  set  storage 
directories  and  storage  names.  In  the  simple  Unix  or 
MS  DOS  case,  the  full  file  path  is  the  concatenation  of 
MDAS_STOR_NAM  to  MDAS-STOR_DIR.  When 
inquiring  about  data  sets,  MDAS_STOR_NAM  may  be 
used  to  match  the  O/S  or  server  name  of  an  arbitrary 
data  set  or  data  set  replicate  (see 
MDAS_REPLICATES  below).  When  scanning 
MDAS_STOR_NAM  from  Info  returned  by 
MDAS_INQUIRE(),  the  value  may  represent  either  (a) 
the  “storage  name”  for  an  unreplicated  data  set  or  (b) 
the  “storage  name”  of  some  replicate  of  the  data  set 
(an  element  of  MDAS_REPL_NAM).  When  adding 
attributes  to  an  Info  structure  for  Catalog  registration, 
use  MDAS-REPL-NAM  with 
MDAS_INFO_SET_RATTR(). 
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MDAS-DATASET  attribute 

Type 

Use 

(Data  Set  Owner) 
MDAS.STOR.OWN 

M  DAS  Jnteger 

Catalog  id#  of  logical  owner  of  the  data  set  or  a 
specific  replicate.  When  inquiring  about  data  sets, 
MDAS-STOR-OWN  may  be  used  to  match  the  owner 
of  an  arbitrary  data  set  or  data  set  replicate  (see 
MDAS.REPLICATES  below).  Scanning 
MDAS_STOR_OWN  from  Info  returned  by 
MDASJNQUIREO  with 

MDASJNFO_SCAN_ATTR(info,  MDAS_STOR_OWN, 
owner,  status)  the  logical  owner  of  the  data  set.  Use 

M  DAS  .REP  L  _OWN  with 

M D A S  JN F 0 _S ET_R ATT R ( )  or 

MDAS  JNFO_SCAN_RATTR()  to  reference  the  owner 
of  a  particular  replicate. 
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MDAS.DATASET  attribute  Type _ 

(Data  Set  SpecHist) 

MDAS-STOR.HSA  MDASinteger 


Use 


Catalog  id#  of  some  action  listed  in 
MDAS.STOR.HSAV  for  a  logical  data  set.  When 
inquiring  about  data  sets,  MDAS_STOR_HSA  may  be 
used  to  match  an  action  tracked  for  a  particular  data 
set.  To  scan  or  set  MDAS_STOR_HSA  Info,  use 
MDAS.STOR.HSC  and  MDAS_STOR_HSAV. 


MDAS_STOR_HST 


MDAS_STOR_HSS 


MDAS_STOR_HSC 


M  DAS  Time 


Time  stamp  for  some  spectral  history  of  an  action  for  a 
logical  data  set.  When  inquiring  about  data  sets, 
MDAS_STOR_HST  may  be  used  to  match  time  stamps 
of  spectral  history  compilations  for  actions  on  a 
particular  data  set.  To  scan  or  set  MDAS_STOR_HST 
Info,  use  MDAS.STOR_HSC  and  MDAS_STOR_HSTV. 


MDAS_spectrum 


Spectral  histories  of  an  action  for  a  logical  data  set. 
When  inquiring  about  data  sets,  MDAS_STOR_HSS 
may  be  used  to  match  spectral  history  compilations  for 
arbitrary  actions  on  a  particular  data  set.  To  scan  or 
set  MDAS_STOR_HSS  Info,  use  MDAS_STOR_HSC 
and  MDAS_STOR_HSSV. 


M  DAS  integer 


#  of  actions  listed  in  MDAS_STOR_HSAV, 
MDAS_STOR_HSTV,  and  MDAS_STOR.HSSV.  When 
inquiring  about  data  sets,  MDAS_STOR_HSC  may  be 
used  to  match  the  count  of  actions  tracked  to  date  for 
a  particular  data  set.  When  scanning 
MDAS-STOR_HSC  from  data  set  Info  returned  by 
MDASJNQUIRE0,  the  value  is  the  actual  count  for  a 
particular  data  set.  When  adding  attributes  to  an  Info 
structure  for  Catalog  registration,  set 
MDAS-STOR_HSC  before  making  incremental  adds  of 
MDAS-STOR.HSAV  or  MDAS_STOR_HSSV. 


MDAS.STOR.HSAV 


MDAS_STOR-HSTV 


MDASJ3TOR_HSSV 


MDASinteger 

array 


Array  of  Catalog  id#’s  of  actions  logical  data  set. 
When  inquiring  about  data  sets,  MDAS_STOR_HSAV 
may  be  used  to  match  a  set  of  actions  tracked  for  a 
particular  data  set.  To  scan  MDAS_STOR_HSAV  Info, 
first  scan  MDAS_STOR_HSC  and  allocate  an  array  of 
that  size,  then  use  MDAS_INFOJSCAN_ATTR(info, 
MDAS_STOR_HSAV,  userarray,  status). 


Time  stamps  of  spectral  history  compilations  for  a 
logical  data  set.  When  inquiring  about  data  sets, 
MDAS_STOR_HSTV  may  be  used  to  match  the  time 
stamp  array  for  spectral  history  compilations  on  a 
particular  data  set.  To  scan  MDAS_STOR_HSTV  Info, 
first  scan  MDAS_STOR_HSC  and  allocate  an  array  of 
that  size,  then  use  MDAS_INFO_SCAN_ATTR(info, 
MDAS_STOR_HSTV,  userarray,  status). 

MDAS_spectrun  Spectral  histories  for  a  logical  data  set.  W7hen 
array  inquiring  about  data  sets,  MDAS_STOR_HSSV  may  be 

used  to  match  entire  spectral  history  sets  a  particular 
data  set.  To  scan  MDAS_STOR_HSSV  Info,  first  scan 
MDAS_STOR_HSC  and  allocate  an  array  of  that  size, 
then  use  MDAS JNFO_SCAN_ATTR(info, 
MDAS_STOR_HSSV,  userarray,  status). 


MDAS-time 

array 
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M DAS -DATASET  attribute 

Type 

Use 

(Data  Set  Perf) 

MDASJ5T0R.PERF 

TBD 

TBD. 

MDAS.DATASET  attribute 

Type 

Use 

(Data  Set  Lock) 

MDAS_STOR_RLCK 

MDASJogical 

Read  access  lock  flag  for  logical  data  set  (all  replicates 
and  segments).  “True”  means  read  access  to  data  set  is 
locked. 

MDAS-STOR.RLCKS 

M  DAS  .time 

Start  time  for  read  access  lock  flag  for  logical  data  set 
(all  replicates  and  segments). 

MDAS-STOR-RLCKE 

M  DAS -time 

End  time  for  read  access  lock  flag  for  logical  data  set 
(all  replicates  and  segments). 

MDAS-STOR.RLCKD 

M  DAS  Jnt  eger 

Domain  Catalog  id#  which  is  allowed  to  set  read  locks 
on  logical  data  set. 

M  D  A  S  _ST  0  R_W  LC  K 

MDASJogical 

Write  access  lock  flag  for  logical  data  set  (all  replicates 
and  segments).  “True”  means  write  access  to  data  set 
is  locked. 

MDAS.STOR.WLCKS 

M  DAS  -time 

Start  time  for  write  access  lock  flag  for  logical  data  set 
(all  replicates  and  segments). 

M  D  AS  _ST  O  R_WL  CK  E 

MDAS_time 

End  time  for  write  access  lock  flag  for  logical  data  set 
(all  replicates  and  segments). 

M  D  AS  _STO  R_W  L  C  K  D 

MDAS  Jnteger 

Domain  Catalog  id#  which  is  allowed  to  set  read  locks 
on  logical  data  set. 

MDAS-DATASET  attribute 

Type 

Use 

(Data  Set  Security) 
MDAS.STORJVUTK 

MDASjstring 

Public  authorization  key  for  logical  data  set  (all 
replicates  and  segments). 

MDAS-STOR-AUTM 

MDASJnteger 

Method  Catalog  id#  for  public  authorization  key. 

MDAS_STOR_RACCK 

MDAS  .string 

Public  read-access  key  for  logical  data  set  (all 
replicates  and  segments). 

MDAS-STOR-RACCM 

MDASJnteger 

Method  Catalog  id#  for  public  read-access  key. 

M  D  AS  -STO  R-WACC  K 

MDAS_string 

Public  write-access  key  for  logical  data  set  (all 
replicates  and  segments). 

MDAS.STOR-WACCM 

I  MDASJnteger 

Method  Catalog  id#  for  public  write-access  key. 

MDAS-STOR.CRYK 

MDAS_string 

Public  encryption  key  for  logical  data  set  (all  replicates 
and  segments). 

MDAS-STOR.CRYM 

MDASJnteger 

Method  Catalog  id#  for  public  encryption  key. 
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M DA S _ D ATA SET  attribute 

Type 

Use 

(Replicates) 

MDAS.REPLICATES 

MDASJnteger 

#  of  data  set  replications.  Replications  are  always 
equivalent  in  content,  but  not  necessarily  in  format  or 
storage  media.  By  default,  an  unreplicated  data  set  is 
replicate  # 1 .  All  replications  have  the  same 

MDASJD,  names,  and  alias5.  Replicates  can  be 
generated  by  either  (a)  a  format  or  storage  translation 
on  an  instance  of  the  data  set,  or  (b)  re-execution  of 
the  method  that  generated  the  original  instance  of  the 
data,  set  but  using  different  target  format  and/or 
storage  parameters.  In  either  case,  the  storage  “Input 
Lineage”  (MDAS_STORJNV)  and  “Generation 

Lineage”  (MDAS.STOR.GEN/GNP/GRC/GNU)  will 
be  the  same  but  “Replication  Lineage”  attributes  will 
vary.  Replicate  attributes  may  be  accessed  with  either 
MDASJNFO.{SET/SCAN}AtTR()  or 
MDASJNFO_{SET/SCAN}_RATTR().  See  individual 
attribute  for  details.  For  case  V,  methods  which 
perform  format  translations  but  otherwise  do  not  alter 
the  content  of  entities  have  MDAS_INVARIENT  set 
“true”.  Data  sets  can  also  be  segmented  (partitioned). 
See  MDAS.REPL.SEGC. 
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MDAS.DATASET  attribute 

Type 

Use 

(Replicate  Group) 
MDAS.REPL.GRPN 

MDAS_string 

Name  of  some  MDAS.GROUP  in  which  this  replicate 
has  membership.  When  specified  in  the  info  argument 
of  MDASJNQUIREQ,  matches  to  data  set  replicates 
with  this  group  will  be  sought;  i.e.,  inquiries  with 
MDAS.REPL.GRPN  are  identical  to  inquiries  with 
MDAS.STOR.GRPN.  Use  MDAS.REPL.GRPNV  to 
scan  or  register  all  the  groups  for  a  particular  data  set 
replicate. 

MDAS.REPL.GRPNC 

MDAS  Jnteger 
array 

MDAS-REPL.GRPNCj  is  the  #  of  MDAS.GROUP 
names  for  replicate  #i. 

MDAS.REPL.GRPNV 

MDAS_string 

array 

Array  of  MDAS.GROUP  names  for  some  data  set 
replicate.  When  specified  in  the  info  argument  of 
MDASJNQUIREQ,  matches  to  replicates  with 
memberships  in  these  particular  groups  will  be  sought. 
The  same  group  memberships  need  not  span  all 
replicates.  To  scan  this  attribute,  use 

MDAS  JNFO.SCAN  JlATTR(info,  i, 
MDAS.REPL.GRPNV,  grpnames,  status).  To  set  this 
attribute,  first  use  MDASJNFO_SET_RATTR(  i, 
MDAS.REPL.GRPNC,  grpcount,  info,  status)  then 
MDASJNFO_SET_RATTR(  i,  MDAS.REPL.GRPNV, 
grpnames,  info,  status). 

MDAS.REPL.GRPI 

MDAS  Jnteger 

Catalog  id#  of  some  MDAS.GROLTP  in  which  this 
replicate  has  membership.  When  specified  in  the  info 
argument  of  MDASJNQUIREQ,  matches  to  data  set 
replicates  with  this  group  will  be  sought;  i.e.,  inquiries 
with  MDAS.REPL.GRPI  are  identical  to  inquiries 
with  MDAS.STOR.GRPL  Use  MDAS.REPL.GRPI V 
to  scan  or  register  all  the  groups  for  a  particular  data 
set  replicate. 

MDAS_REPL_GRPIC 

MDAS  Jnteger 
array 

MDAS_REPL.gr PIC,  is  the  #  of  MDAS.GROUP 
Catalog  id#?s  for  replicate 

MDAS.REPL.GRPIV 

MDASjstring 

array 

Array  of  MDAS.GROUP  Catalog  id#’s  for  some  data 
set  replicate.  When  specified  in  the  info  argument  of 
MDASJNQUIREQ,  matches  to  replicates  with 
memberships  in  these  particular  groups  will  be  sought. 
The  same  group  memberships  need  not  span  all 
replicates.  To  scan  this  attribute,  use 
MDASJNFO_SCAN_RATTR(info,  i, 

MDAS.REPL.GRPI V,  grpids,  status).  To  set  this 
attribute,  first  use  MDAS JNFOJ3ET_RATTR( 
MDAS.REPL.GRPIC,  grpcount.  info,  status)  then 
MDASJNFO_SET_RATTR(  i,  MDAS.REPL.GRPIV, 
grpids,  info,  status). 
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MDAS.DATASET  attribute 

Type 

Use 

(Replicate  Domain) 

M  DAS  JtEP  L  _D  M  N  N 

MDAS_string 

Name  of  some  MDASJDOMAIN  in  which  this  replicate 
has  membership.  When  specified  in  the  info  argument 
of  MDASJNQUIREQ,  matches  to  data  set  replicates 
with  this  domain  will  be  sought;  i.e.,  inquiries  with 
MDASJtEPL  JDMNN  are  identical  to  inquiries  with 
MDAS_STORJDMNN.  Use  MDAS  JIEPLJDMNNV  to 
scan  or  register  all  the  domains  for  a  particular  data 
set  replicate. 

MDAS_REPL_DMNNC 

MDASJnteger 

array 

MDAS_REPL_DMNNC;  is  the  #  of  MDAS_DOMAIN 
names  for  replicate  #i. 

M  D  A  S  _RE  PL.DMNNV 

MDASjstring 

array 

Array  of  MDASJDOMAIN  names  for  some  data  set 
replicate.  When  specified  in  the  info  argument  of 

MDAS  JNQUIREQ,  matches  to  replicates  with 
memberships  in  these  particular  domains  will  be 
sought.  The  same  domain  memberships  need  not  span 
all  replicates.  To  scan  this  attribute,  use 

M D AS  JN FO _SC A N JRATTR(info,  i , 

MDAS  JtEPL.DMNNV,  dmnnames,  status).  To  set 
this  attribute,  first  use  MDAS_INFO_SET_RATTR(  i, 
MDAS  JIEPL.DMNNC,  dmncount,  info,  status)  then 
MDAS  JNFO -SET  JIATTR(  i, 

MDAS  JIEPL-DMNNV,  dmnnames,  info,  status). 

MDAS_REPL_DMNI 

MDASJnteger 

Catalog  id#  of  some  MDASJDOMAIN  in  which  this 
replicate  has  membership.  When  specified  in  the  info 
argument  of  MDAS  JNQUIREQ,  matches  to  data  set 
replicates  with  this  domain  will  be  sought;  i.e., 
inquiries  with  MDAS_REPL  JDMNI  are  identical  to 
inquiries  with  MDASJ3TORJDMNI.  Use 
MDAS_REPL_DMNIV  to  scan  or  register  all  the 
domains  for  a  particular  data  set  replicate. 

MDAS-REPL.DMNIC 

MDASJnteger 

array 

MDAS JlEPL-DMNICh  is  the  #  of  MDASJDOMAIN 
Catalog  id#'s  for  replicate  #i. 

MDAS.REPL.DMNIV 

MDAS_string 

array 

x\rray  of  MDASJDOMAIN  Catalog  id#'s  for  some  data 
set  replicate.  When  specified  in  the  info  argument  of 
MDAS  JNQUIREQ,  matches  to  replicates  with 
memberships  in  these  particular  domains  will  be 
sought.  The  same  domain  memberships  need  not  span 
all  replicates.  To  scan  this  attribute,  use 

MDAS JNFO _SCAN JTATTR(info,  i , 

MDAS-REPL  JDMNI V,  dmnids,  status).  To  set  this 
attribute,  first  use  MDAS JNFO_SET_RATTR(  i, 
MDAS_REPL_DMNIC,  dmncount,  info,  status)  then 
MDAS  JNFO_SET_RATTR(  i,  MDAS.REPLJDMNIV, 
dmnids,  info,  status). 
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MDAS.DATASET  attribute 

Type 

Use 

(Repl.  Input  Lineage) 

MDAS.REPL.IN 

MDAS  .integer 

Catalog  id#  of  an  MDAS.DATASET  source  used  in 
the  creation  of  this  data  set  replicate.  Applies  only  to 
the  replication  of  data  set,  not  segments  or  origination. 
When  inquiring  about  data  sets,  MDAS.REPL JN  may 
be  used  to  match  replication  “lineage” .  When  scanning 
MDAS.REPL.IN  from  Info  returned  by 
MDAS_INQUIRE(),  the  value  is  some  data  set  used  in 
creating  the  replication.  To  obtain  all  inputs  used  to 
create  a  replicate,  use  MDAS JREPL.INV.  When 
adding  attributes  to  an  Info  structure  for  Catalog 
registration,  use  MDAS.REPL.INV. 

MDAS.REPL.INC 

MDAS -integer 

#  of  items  listed  in  MDAS.REPL  JNV.  When 
inquiring  about  data  sets,  MDAS.REPLJNC  may  be 
used  to  match  the  count  of  data  sets  in  replication 
“lineage”.  When  scanning  MDAS.REPLJNC  from 
data  set  Info  returned  by  MDAS JNQUIREQ,  the 
value  is  the  actual  count  of  inputs  to  a  replication 
method  used  to  create  a  particular  data  set  replicate. 
When  adding  attributes  to  an  Info  structure  for 

Catalog  registration,  set  MDAS.REPLJNC  before 
making  incremental  adds  of  MDAS.REPLJN  or 
adding  an  MDAS.REPL.INV  vector. 

MDAS.REPL  JNV 

MDASJnteger 

Array  of  Catalog  id#’s  used  as  inputs  to  a  replication 

array 

method  that  created  some  data  set  replicate.  Applies 
only  to  the  replication  of  a  data  set,  not  segments  or 
origination.  When  inquiring  about  data  sets, 
MDAS.REPLJNC  and  MDAS.REPL  JNV  may  be 
used  to  match  replication  “lineage”.  When  scanning 
MDAS.REPL  JNV  from  Info  returned  by 
MDASJNQUIRE(),  the  value  is  some  vector  of  input 
data  set  id#’s  used  to  create  one  of  the  data  set 
replications.  When  adding  attributes  to  an  Info 
structure  for  Catalog  registration,  first  use 
MDASJNFO_SET_RATTR(  i,  MDAS.REPLJNC, 
incount,  info,  status)  and  then  use 

M  D  AS  J  N  FO.S  ET.R  ATTR(  »,  MDAS.REPL  JNV, 
rlinvect,  info,  status). 
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MDAS.DATASET  attribute 

Type 

Use 

(Repl.  Conseq.  Lineage) 
MDAS_REPL_OUT 

MDAS_integer 

Catalog  id#  of  an  MDAS.DATASET  data  set 
replicate  produced  from  another  data  set  replicate. 
Applies  only  to  the  replication  of  data  set,  not 
segments  or  origination.  When  inquiring  about  data 
sets,  MDAS_REPL_OUT  may  be  used  to  match 
replication  “consequential  lineage”.  W7hen  scanning 
MDAS_REPL_OUT  from  Info  returned  by 

MDAS  JNQUIRE0,  the  value  is  the  Catalog  id#  of 
some  data  replicate  set.  To  add  this  value  for  Catalog 
registration,  use  MDAS_INFO-SET_RATTR(  *, 
MDAS_REPL_OUT,  rlout,  info,  status).  To  obtain  all 
replicates  produced  from  another  replicate,  use 
MDAS.REPL.OUTV. 

M  D  AS  _RE  P  L  _0  UT  VC 

MDAS  Jnteger 

#  of  items  listed  in  MDAS  JLEPL.OUTV.  When 
inquiring  about  data  sets,  MDAS  JIEPL  JDUTVC  may 
be  used  to  match  the  count  of  data  sets  in  replication 
“consequential  lineage”.  When  scanning 
MDAS_REPL_OUTVC  from  data  set  Info  returned  by 
MDASJNQUIREQ,  the  value  is  the  actual  count  of 
replicates  created  from  a  particular  data  set  replicate. 
When  adding  attributes  to  an  Info  structure  for 

Catalog  registration,  set  MDAS  JIEPL.OUTVC  before 
making  incremental  adds  of  MDAS  JIEPL.OUT  or 
adding  an  MDAS_REPL_OUTV  vector. 

MDAS.REPL.OUTV 

MDASJnteger 

array 

! 

Array  of  Catalog  id#\s  used  as  inputs  to  a  replication 
method  that  created  some  data  set  replicate.  Applies 
only  to  the  replication  of  a  data  set,  not  segments  or 
origination.  When  inquiring  about  data  sets, 
MDAS_REPL_OUTVC  and  MDAS_REPL_OUTV  may 
be  used  to  match  replication  “consequential  lineage”. 
When  scanning  MDAS_REPL_OUTV  from  Info 
returned  by  MDASJNQUIREQ,  use 

M D AS JN F 0 _S ET _R ATT R(  i,  MDAS.REPL.OUTVC, 
outcount,  info,  status)  and  then 
MDASJNFO_SCANJtATTR(  i, 

MDAS_REPL_OUTV,  rloutvect,  info,  status).  When 
adding  attributes  to  an  Info  structure  for  Catalog 
registration,  first  use  MDAS JNFOJ3ET JIATTR(  z, 
MDAS  JIEPL.OUTVC,  outcount,  info,  status)  and 
then  use  MDAS  JNFO_SET-RATTR(  z‘, 
MDAS_REPL_OUTV,  rloutvect,  info,  status). 
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MDAS -DATASET  attribute 


(Repl.  Gen.  Lineage) 
MDAS.REPL.GEN 


MDASJnteger 


Catalog  id #  of  an  MDAS .METHOD  which  generated 
this  data  set  replicate.  Applies  only  to  the  replication 
of  a  data  set,  not  segments  or  origination.  When 
inquiring  about  data  set  replicates,  MDAS.REPL.GEN 
may  be  used  to  match  “replication  method  lineage”. 
When  scanning  MDAS.REPL.GEN  from  data  set  Info 
returned  by  MDAS  JNQUIREQ,  use 
MDASJNFOJSCANJtATTR(«\  MDAS.REPL.GEN, 
rmethod,  info,  status)  to  find  the  method  used  to 
produce  replicate  i.  Likewise,  use 

MDASJNFO_SET_RATTR(i,  MDAS.REPL.GEN, 

rmethod,  info,  status)  to  specify  the  method  used  to 
produce  replicate  i.  The  ordering  of  inputs  specified  in 
MDAS.REPL.INV  must  match  the  ordering  of  inputs 
defined  in  the  Catalog  metadata  for 
MDAS.REPL.GEN. 


MDAS.REPL.GNP 


MDAS-REPL.GNR 


MDAS.REPL.GNU 


MDAS_string  The  parameter  list  (if  any)  used  with 

MDAS.REPL.GEN  to  generate  this  data  set 
replicate.  Applies  only  to  the  replication  of  a  data 
set,  not  segments  or  origination.  When  inquiring  about 
data  set  replicates,  MDAS.REPL.GNP  may  be  used  to 
match  method  “replication  method  lineage”.  When 
scanning  MDAS.REPL.GNP  from  data  set  Info 
returned  by  MDAS  JNQUIREQ,  use 
M D AS_INFO.SCAN_RATTR( i,  MDAS.REPL.GNP, 
rparams,  info,  status)  to  find  the  method  parameters 
used  to  produce  replicate  i.  Likewise,  use 
M D A S _I N FO _S ET.R ATT R ( i ,  MDAS.REPL.GNP, 
rparams,  info,  status)  to  specify  the  parameters  used 
to  produce  replicate  i.  The  format  of 
MDAS.REPL.GNP  must  match  the  parameter  format 
required  for  MDAS.REPL.GEN. 

MDASJnteger  Catalog  id#  of  the  M  DAS  .RES  O  URGE  on  which 
MDAS.REPL.GEN  executed  to  create  the  data  set 
replicate.  Applies  only  to  the  replication  of  a  data 
set,  not  segments  or  origination.  When  inquiring  about 
data  set  replicates,  MDAS-REPL.GNR  may  be  used  to 
match  method  “replication  method  lineage”.  When 
scanning  MDAS.REPL.GNR  from  data  set  Info 
returned  by  MDAS.INQUIREQ,  use 
M D AS JN FO .S C A N JR. ATT R( if  MDAS.REPL.GNR, 
replrsrc,  info,  status)  to  find  the  resource  where 
replicate  i  was  produced. 

MDASJnteger  Catalog  id#  of  the  MDAS.USER  which  executed 

MDAS.REPL.GEN  to  create  the  data  set  replicate. 
Applies  only  to  the  replication  of  a  data  set,  not 
segments  or  origination.  When  inquiring  about  data 
set  replicates,  MDAS.REPL.GNU  may  be  used  to 
match  method  “replication  method  lineage”.  When 
scanning  MDAS.REPL.GNLI  from  data  set  Info 
returned  by  MDAS_INQUIRE(),  use 
MDASJNFO.SCAN-RATTRQ,  MDAS.REPL.GNU, 
repluser,  info,  status)  to  find  the  user  that  produced 
replicate  i. 
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MDAS.DATASET  attribute 

Type 

Use 

(Replication  Trigger) 
MDAS-REPL.TRGM 

MDASinteger 

Catalog  MDAS.METHOD  id#  of  some  trigger  for  a 
data  set  replicate.  These  replication  methods  are 
executed  when  updates  are  made  to  this  data  set  and 
the  corresponding  trigger  policy  evaluates  to  “true”. 
When  inquiring  about  data  sets,  MDAS.REPL.TRGM 
may  be  used  to  match  data  set  replication  triggers. 

When  scanning  MDAS_REPL_TRGM  from  data  set 

Info  returned  by  MDASJNQUIREQ,  the  value 
returned  is  some  element  of  MDAS_REPL_TRGMV. 
When  adding  attributes  to  an  Info  structure  for 

Catalog  registration,  use  MDAS_REPL_TRGC  and 
MDAS-REPL.TRGMV  to  avoid  ambiguous  behavior. 

MDAS-REPL-TRGP 

M  DAS  integer 

Catalog  MDAS.POLICY  id#  of  some  trigger  policy  for 
a  data  set  replicate.  Replication  triggers  are  executed 
when  updates  are  made  to  this  data  set  replicate  and 
the  corresponding  trigger  policy  evaluates  to  “true”. 
When  inquiring  about  data  set  replicates, 
MDAS_REPL_TRGP  may  be  used  to  match  data  set 
replication  policies.  When  scanning 

MDAS_REPL_TRGP  from  data  set  Info  returned  by 
MDASJNQUIREQ,  the  value  returned  is  some 
element  of  MDAS-REPL.TRGPV.  When  adding 
attributes  to  an  Info  structure  for  Catalog  registration, 
use  MDAS-REPL.TRGC  and  MDAS-REPL.TRGPV 
to  avoid  ambiguous  behavior. 

MDAS.REPL.TRGC 

MDAS_integer 

#  of  triggers  and  trigger  policies  listed  in 
MDAS-REPL-TRGMV  and  MDAS-REPL.TRGPV  for 
some  replicate.  When  scanning  MDAS-REPL.TRGC 
from  Info  returned  by  MDASJNQUIREQ,  use 
MDAS-INFO_SCAN-RATTRQ\  MDAS.REPL.TRGC, 
repltrgc,  info,  status)  to  find  the  number  of  replication 
triggers  for  replicate  i.  Likewise,  use 
MDASJNFO-SET-RATTRQ,  MDAS-REPL.TRGC, 
repltrgc,  info,  status)  to  specify  the  replication  trigger 
count  for  replicate  i. 

MDAS-REPL.TRGMV 

MDAS_integer 

array 

Array  of  method  Catalog  id#’s.  These  methods  are 
executed  when  updates  are  made  to  this  data  set  and 
the  corresponding  policy  in  MDAS-REPL.TRGPV 
evaluates  to  “true”.  To  scan  the  entire  array  for 
replicate  i ,  first  obtain  MDAS.REPL.TRGC  and 
allocate  an  array  of  that  size.  Scan  values  into  the 
array  with  MDASJNFO_SCAN_RATTR(«, 
MDAS.REPL.TRGMV,  repltrgmv,  info,  status). 

MDAS-REPL.TRGPV 

MDASJnteger 

array 

Array  of  policy  Catalog  id#’s  for  triggers  in 
MDAS-REPL.TRGMV.  To  scan  the  entire  array  for 
replicate  i,  first  obtain  MDAS.REPL.TRGC  and 
allocate  an  array  of  that  size.  Scan  values  into  the 
array  with  MDAS JNFO_SCAN_RATTR(L 
MDAS-REPL.TRGPV,  replt.rgpv,  info,  status). 
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M DAS _DATA SET  attribute 

Type 

Use  "  ^ 

(Repl.  Re-Gen.  Policy) 

M  D  AS  _RE  P  L  _P  LC  Y 

M  DAS  integer 

Update  policy  for  a  data  set  replicate.  When 
inquiring  about  data  set  replicates, 

MDAS.REPL.PLCY  may  be  used  to  match 
“replication  regeneration  policies”.  Applies  only  to  the 
replication  of  a  data  set,  not  segments  or  origination. 
When  scanning  MDAS  .REPL  .PLCY  from  Info 
returned  by  MDAS JNQUIRE(),  use 

M D AS JN FO _S C A N Jl ATT R ( i ,  MDAS.REPL.PLCY, 
replplcy,  info,  status)  to  find  the  policy  that  produced 
replicate  i.  Likewise,  use  MDAS  JNFO_SET_RATTR(z, 
MDAS.REPL.PLCY,  replplcy,  info,  status)  to  specify 
the  policy  for  regeneration  of  replicate  i. 

M DAS _DATA S ET  attribute 

Type 

Use 

(Replicate  Dates) 

MDAS.REPL.DATE 

MDAS.time 

The  creation  time  for  some  replicate.  When  inquiring 
about  data  sets,  MDAS_REPL_DATE  may  be  used  to 
match  the  creation  date  of  an  arbitrary  data  set 
replicate.  When  scanning  MDAS_REPL_DATE  from 

Info  returned  by  MDAS  JNQUIREQ,  the  value 
represents  the  creation  date  of  some  replicate  of  the 
data  set  (an  element  of  MDAS_REPL_DATEV).  To 
obtain  the  creation  time  for  a  specific  replicate  *,  use 
MDASJNFO_SCAN_RATTR(z,  MDAS.REPLJDATE, 
repldate,  info,  status).  When  adding  attributes  to  an 

Info  structure  for  Catalog  registration,  use 

M D AS J N  FO  _S  ET.R  ATT  R( i ,  MDAS.REPLJDATE, 
repldate,  info,  status). 

MDAS-REPL.DATEV 

MDAS  _t,ime 

MDAS-REPL.DATEV,  is  the  creation  time  for 

array 

replicate  i.  This  array  can  be  scanned  and  set  with 
MDASJNFO_SCANl\TTR(info, 

MDAS_REPL_DATEV.  userarray,  status)  and 

M  D  AS  JN  FO  _S  ET  _ATTR  ( MDAS  .REPL  .D  ATE  V, 
userarray,  info,  status). 
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MDAS.DATASET  attribute 

Type 

Use 

(Replicate  Permanence) 
MDASJIEPL.PERM 

M  DAS  .double 

Probability  of  some  replicate  not  being  purged 
(permanence).  When  inquiring  about  data  sets, 
MDAS.REPL.PERM  may  be  used  to  match  the 
permanence  of  an  arbitrary  data  set  replicate.  When 
scanning  MDAS_REPL_PERM  from  Info  returned  by 
MDASJNQUIRE(),  use 

MDASJNFOJSCANJlATTR(i>  MDAS.REPL.PERM, 

replperm,  info,  status)  to  obtain  the  permanence  value 
for  replicate  i .  When  adding  attributes  to  an  Info 
structure  for  Catalog  registration,  use 
MDASJNFO_SET.RATTR(z,  MDAS_REPL_PERM, 
replperm,  info,  status).  See  also 

MDAS-REPL.PERMV. 

MDAS.REPL.PERMV 

M  DAS -double 

array 

MDAS_REPL_PERMVj  is  the  permanence  value  for 
replicate  i.  This  array  can  be  scanned  and  set  with 
MDASJNFO_SCAN_ATTR(info, 

MDAS_REPL-PERMV,  userarray,  status)  and 
MDASJNFO.SET_ATTR(MDAS_REPL_PERMV, 
userarray,  info,  status). 

MDAS-REPL.PURG 

MDAS  Jogical 

i 

True  if  replicate  has  been  purged.  When  inquiring 
about  data  sets,  MDAS_REPL_PURG  may  be  used  to 
match  the  purge  status  of  an  arbitrary  data  set 
replicate.  When  scanning  MDAS_REPL_PURG  from 

Info  returned  by  MDAS  JNQUIRE(),  use 
MDASJNFO.SCAN_RATTR(«,  MDAS-REPL.PURG, 
replpurg,  info,  status)  to  obtain  the  purge  truth  value 
for  replicate  i.  When  adding  attributes  to  an  Info 
structure  for  Catalog  registration,  use 
MDAS_INFO_SET_RATTR(?‘,  MDAS.REPL.PURG, 
replpurg,  info,  status). 

MDAS.REPL.PURGV 

MDAS  Jogical 
array 

MDAS-REPL_PURGVt  is  true  if  replicate  i  has  been 
purged.  This  array  can  be  scanned  and  set  with 
MDASJNFO-SCAN_ATTR(info, 

MDAS.REPL.PURGV,  userarray,  status)  and 
MDASJNFO_SET_ATTR(MDAS_REPL_PURGV, 
userarray,  info,  status). 
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MDASJDATASET  attribute 

Type 

Use 

(Replicate  Sizes) 

MDASJEtEPL-SIZE 

MDAS_size 

The  size  of  a  data  set  replicate.  When  inquiring 
about  data  sets,  MDASJIEPL.SIZE  may  be  used  to 
match  the  size  of  an  arbitrary  data  set  replicate.  When 
scanning  MDAS.REPL.SIZE  from  Info  returned  by 
MDAS  JNQUIREQ,  the  value  represents  the  size  of 
some  replicate  of  the  data  set  (an  element  of 
MDAS.REPL.SIZEV).  To  obtain  the  creation  time  for 
a  specific  replicate  i ,  use 

MDASJNFO_SCAN_RATTR(i,  MDAS.REPL.SIZE, 
replsize,  info,  status).  When  adding  attributes  to  an 

Info  structure  for  Catalog  registration,  use 
MDASJNFO.SET_RATTR(«,  MDAS.REPL.SIZE, 
replsize,  info,  status). 

MDAS.REPL.SIZEV 

MDASjsize 

MDAS.REPL.SIZEV*  is  the  creation  time  for  replicate 

array 

i.  This  array  can  be  scanned  and  set  with 
MDASJNFO.SC  AN_ATTR(info, 

MDAS.REPL.SIZEV,  userarray,  status)  and 
MDASJNFO.SET.ATTR(MDAS_REPL_SIZEV, 

userarray,  info,  status). 
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MD  AS  .DATASET  attribute 

Type 

Use 

(Replicate  Format) 
MDAS-REPL.FMTH 

MDASJogical 

True  when  a  data  set  replicate  has  heterogeneous 
format  segments.  To  scan  this  attribute,  use 
MDASJNFO_SCAN_RATTR(z,  info, 
MDAS-REPL.FMTH,  hflag,  status).  See 
MDAS.REPL.SEGC. 

Note:  a  data  set  replicate 
with  heterogeneous  format 
segments  will  not  have  any 
data  in  the  format 
attributes  below.  See 
MDAS_REPL_SEGC. 

MDAS_REPL-FMTN 

MDASjstring 

The  name  (or  alias)  of  the  format  of  some  data  set 
replicate.  When  inquiring  about  data  sets, 
MDAS_REPL_FMTN  may  be  used  to  match  the 
format  of  an  arbitrary  data  set  replicate.  To  obtain  the 
format  name  of  a  specific  replicate  z,  use 

M D AS JN FO _SC A N JRA.TT  R(  z ,  MDAS_REPL_FMTN, 
replfmtn,  info,  status).  When  adding  attributes  to  an 
Info  structure  for  Catalog  registration,  use 

M DAS _I N F CLS ET _R ATT R(  z ,  MDAS_REPL_FMTN, 
replfmtn,  info,  status).  See  MDAS_REPL_FMTNV. 

MDAS_REPL_FMTNV 

M  DAS  string 
array 

MDAS-REPL_FMTNVt  is  the  format  name  (or  alias) 
of  replicate  z.  This  array  can  be  scanned  and  set  with 
MDASJNFO_SCAN_ATTR(info, 

MDAS_REPL_FMTNV,  userarray,  status)  and 
MDASJNFO-SET  _AT  T  R  ( M  D  A  S  _R  E  P  L  _  F  M  T  N  V , 
userarray,  info,  status). 

MDAS_REPL_FMTI 

i 

M  DAS  integer 

:  The  Catalog  id#  of  the  format  of  some  data  set 
replicate.  When  inquiring  about  data  sets, 
MDAS_REPL_FMTI  may  be  used  to  match  the  format 
of  an  arbitrary  data  set  replicate.  To  obtain  the  format 
id#  of  a  specific  replicate  z,  use 
MDASJNFO_SCAN_RATTR(z,  M DAS _RE P L _F MTI , 
replfmti,  info,  status).  When  adding  attributes  to  an 

Info  structure  for  Catalog  registration,  use 

M DAS  J  N  FO  _S ET_R ATT R( i ,  MDAS_REPL_FMTI, 
replfmti,  info,  status).  See  MDAS_REPL_FMTIV. 

MDAS-REPL.FMTIV 

MDASJnteger 

array 

MDAS-REPL-FMTIVi  is  the  format  Catalog  id#  of 
replicate  z.  This  array  can  be  scanned  and  set  with 
MDASJNFO_SCANl\TTR(info, 

MDAS_REPL_FMTIV,  userarray,  status)  and 

MDAS  JNFO_SET_ATTR(MDAS_REPL_FMTIV, 
userarray,  info,  status). 

56 


M DAS _DATASET  attribute 

Type 

Use 

(Re pi.  Storage  Resource  ) 
MDAS-REPLJR.SCH 

MDASJogical 

True  when  a  data  set  replicate  has  heterogeneous 
format  segments.  To  scan  this  attribute,  use 
MDASJNFCLSCAN_RATTR(i,  info, 
MDAS-REPL-RSCH,  hflag,  status).  See 
MDAS-REPL.SEGC. 

Note:  a  data  set  replicate 
with  distributed  storage 
segments  will  not  have  any 
data  in  the  resource 
attributes  below.  See 
MDAS-REPL.SEGC. 

MDAS.REPL.RSCN 

M  DAS  string 

The  name  (or  alias)  of  a  storage  resource  for  some  data 
set  replicate.  When  inquiring  about  data  set  replicates, 
MDAS-REPL-RSCN  may  be  used  to  match  the  name 
of  a  storage  resource  for  an  arbitrary  data  set  replicate. 
To  obtain  the  storage  resource  name  of  a  specific 
replicate  i,  use  MDAS JNFO_SCAN_RATTR(z, 
MDAS_REPL_RSCN,  replrscn,  info,  status).  When 
adding  attributes  to  an  Info  structure  for  Catalog 
registration,  use  MDAS _INFO_SET_RATTR(«, 
MDAS_REPL_RSCN,  replrscn,  info,  status).  See 
MDAS-REPL_RSCN  V. 

M  D  AS  _RE  P  L  _R  SC  N  V 

MDAS_string 

array 

MDAS_REPL_RSCN Vt  is  the  storage  resource  name 
(or  alias)  of  replicate  i.  This  array  can  be  scanned  and 
set  with  MDAS_INFO_SCAN_ATTR(info, 
MDAS-REPL_RSCNV,  userarray,  status)  and 
MDASJNFO_SET_ATTR(MDAS_REPL_RSCNV, 
userarray,  info,  status). 

MDAS_REPL_RSCI 

MDASJnteger 

The  Catalog  id#  of  a  storage  resource  for  some  data 
set  replicate.  When  inquiring  about  data  set  replicates, 
MDAS_REPL_RSCI  may  be  used  to  match  the  id#  of 
a  storage  resource  for  an  arbitrary  data  set  replicate. 

To  obtain  the  storage  resource  id#  of  a  specific 
:  replicate  i,  use  MDAS JNFO_SCAN_RATTR(i, 
MDAS-REPL-RSCI,  replrsci,  info,  status).  When 
adding  attributes  to  an  Info  structure  for  Catalog 
registration,  use  MDAS  JNFO_SET_RATTR(z, 
MDAS-REPL_RSCI,  replrsci,  info,  status).  See 

MDAS -REPL-RSCIV. 

MDAS_REPL_RSCIV 

M  DAS  .integer 
array 

MDAS-REPL_RSCIVj  is  the  storage  resource  Catalog 
id#  of  replicate  i.  This  array  can  be  scanned  and  set 
with  MDAS_INFOJ3CAN_ATTR(info, 
MDAS-REPL-RSCIV,  userarray,  status)  and 
MDASJNFO_SET_ATTR(MDAS_REPL_RSCIV, 
userarray,  info,  status). 
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MDAS-DATASET  attribute 

Type 

Use 

(Repl.  Storage  Server  ) 
MDASJtEPL-SRVH 

M  DAS -logical 

True  when  a  data  set  replicate  has  heterogeneous 
format  segments.  To  scan  this  attribute,  use 
MDASJNFO_SCAN_RATTR(i,  info, 
MDAS_REPL_SRVH,  hflag,  status).  See 
MDAS_REPL_SEGC. 

Note:  a  data  set  replicate 
with  heterogeneous 
storage  service  segments 
will  not  have  any  data  in 
the  server  attributes 
below.  See 

MDAS_REPL_SEGC. 

MDAS-REPL.SRVN 

MD  AS -string 

The  name  (or  alias)  of  a  storage  resource  server  for 
some  data  set  replicate.  This  might  be  the  O/S  for  the 
storage  resource,  or  a  specialized  service  provider. 

When  inquiring  about  data  set  replicates, 
MDAS_REPL_SRVN  may  be  used  to  match  the  name 
of  a  storage  resource  server  for  an  arbitrary  data  set 
replicate.  To  obtain  the  storage  resource  server  name 
of  a  specific  replicate  i ,  use 

MDAS  JNFO_SCANJLATTR(i,  M DAS _R E P L _S RVN , 
replsrvn,  info,  status).  When  adding  attributes  to  an 

Info  structure  for  Catalog  registration,  use 

M D AS J N F O _S ET -R ATT R(i,  MDASJREPL-SRVN, 
replsrvn,  info,  status).  See  MDAS_REPL_SRVNV. 

M  D  AS.REP  L.S  RVN  V 

MDAS-string 

array 

MDAS.REPL-SRVNV*  is  the  storage  resource  server 
name  (or  alias)  of  replicate  i.  This  array  can  be 
scanned  and  set  with  MDAS_INFO_SCAN_ATTR(info, 
MDAS_REPL_SRVNV,  userarray,  status)  and 

MDAS  JNFO_SET_ATTR(MDAS-REPL_SRVNV, 
userarray,  info,  status). 

MDAS.REPL-SRVI 

M  DAS  integer 

The  Catalog  id#  of  a  storage  resource  server  for  some 
data  set  replicate.  This  might  be  the  O/S  for  the 
storage  resource,  or  a  specialized  service  provider. 

When  inquiring  about  data  set  replicates, 
MDAS_REPL_SRVI  may  be  used  to  match  the  id#  of 
a  storage  resource  server  for  an  arbitrary  data  set 
replicate.  To  obtain  the  storage  resource  server  id#  of 
a  specific  replicate  i,  use 

MDASJNFO-SCAN_RATTR(z,  MDAS-REPL-SRVI, 
replsrvi,  info,  status).  When  adding  attributes  to  an 

Info  structure  for  Catalog  registration,  use 
MDASJNFO_SET_RATTR(i,  MDAS-REPL_SRVI, 
replsrvi,  info,  status).  See  MDAS.REPL-SRVIV. 

MDAS.REPL-SRVIV 

M  DAS  integer 
array 

MDAS_REPL_SRVIVt  is  the  storage  resource  server 
Catalog  id#  of  replicate  i.  This  array  can  be  scanned 
and  set  with  MDAS  JNFO_SCAN_ATTR(info, 
MDAS-REPL-SRVIV,  userarray,  status)  and 
MDASJNFO_SET_ATTR(MDAS_REPL_SRVIV, 
userarray,  info,  status). 
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M  DAS  .DATASET  attribute 

Type 

Use 

(Repl.  Dir.  and  Name  ) 

Note:  a  data  set  replicate 
with  heterogeneous 
storage  segments  will  not 
have  any  data  in  the 
directory  and  name 
attributes  below.  See 
MDAS.REPL.SEGC. 

MDAS_REPL_DIRN 

MDAS-string 

The  storage  “directory”  for  some  data  set  replicate. 
MDAS  distinguishes  between  data  set  storage 
directories  and  storage  names .  In  the  simple  Unix  or 

MS  DOS  case,  the  full  file  path  is  the  concatenation  of 
MDAS-REPL.NAM  to  MDAS_REPL_DIR.  When 
inquiring  about  data  set  replicates, 

MDAS.REPL.DIRN  may  be  used  to  match  the  storage 
directory  for  an  arbitrary  data  set  replicate.  To  obtain 
the  storage  directory  of  a  specific  replicate  i,  use 
MDASJNFO_SCAN_RATTR(i,  MDAS.REPL.DIRN, 
repldirn,  info,  status).  When  adding  attributes  to  an 

Info  structure  for  Catalog  registration,  use 

M D AS JN FO _S ET_R ATT R( * ,  MDAS_REPL_DIRN, 
repldirn,  info,  status).  See  MDAS_REPL_DIRNV. 

MDAS-REPL.DIRNV 

M  DAS  .string 
array 

MDAS-REPL JDIRNVt  is  the  storage  directory  of 
replicate  i.  This  array  can  be  scanned  and  set  with 
MDASJNFO_SCAN_ATTR(info, 

MDAS-REPL.DIRNV,  userarray,  status)  and 
MDAS_INFO_SET_ATTR(MDAS_REPL_DIRNV, 

userarray,  info,  status). 

MDAS-REPL.NAMN 

MDAS_string 

The  O/S  or  server  name  for  some  data  set  replicate. 
MDAS  distinguishes  between  data  set  storage 
directories  and  storage  names .  In  the  simple  Unix  or 

MS  DOS  case,  the  full  file  path  is  the  concatenation  of 
MDAS-REPL.NAM  to  MDAS -REPL.DIR.  When 
inquiring  about  data  set  replicates, 

MDAS-REPL.NAMN  may  be  used  to  match  the  O/S 
or  server  name  for  an  arbitrary  data  set  replicate.  To 
obtain  the  O/S  or  server  name  of  a  specific  replicate  i , 
use  MDAS_INFO_SCAN_RATTR(L 
MDAS.REPL-NAMN,  replnamn,  info,  status).  WThen 
adding  attributes  to  an  Info  structure  for  Catalog 
registration,  use  MDAS  JNFO_SET_RATTR(L 
MDAS-REPL.NAMN,  replnamn.  info,  status).  See 
MDAS-REPL.NAMNV. 

MDAS.REPL.NAMNV 

MDAS_string 

array 

MDAS.REPL.NAMNV*  is  the  O/S  or  server  name  of 
replicate  i.  This  array  can  be  scanned  and  set  with 

M  D  A  S  _I  N  F  0  _S  C  AN  _ATT  R  (info , 

MDAS_REPL_NAMNV,  userarray,  status)  and 
MDAS_INFO_SET_ATTR(MDAS_REPL.NAMNV, 
userarray,  info,  status). 
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MDAS^DATASET  attribute 

Type 

Use 

(Replicate  Owner  ) 

MDAS-REPL.OWN 

MDASjstring 

An  M DAS _USER  Catalog  id#  for  the  owner  of  some 
data  set  replicate.  When  inquiring  about  data  set 
replicates,  MDAS_REPL_OWN  may  be  used  to  match 
the  owner’s  Catalog  id#  for  an  arbitrary  data  set 
replicate.  To  obtain  the  owner  id#  of  a  specific 
replicate  i,  use  MDAS JNFO_SCAN-RATTR()\ 
MDAS.REPL-OWN,  replown,  info,  status).  When 
adding  attributes  to  an  Info  structure  for  Catalog 
registration,  use  MDAS JNFO_SET_RATTR(«, 
MDAS_REPL_OWN,  replown,  info,  status).  See 
MDAS_REPL_OWNV. 

MDAS_REPL_OWNV 

MDASjstring 

MDAS-REPL_OWNVt  is  the  storage  directory  of 

array 

replicate  i.  This  array  can  be  scanned  and  set  with 
MDASJNFO_SCAN-ATTR(info, 

MDAS_REPL_OWNV,  userarray,  status)  and 
MDASJNFO_SET_ATTR(MDAS_REPL_OWNV, 
userarray,  info,  status). 

MDAS. DATASET  attribute 
(Replicate  SpecHist) 
MDAS.REPL.HSA 


MDAS-REPL.HST 


MDAS.REPL.HSS 


MDAS.REPL.HSC 


MDAS_REPL_HSAV 


MDAS.REPL.HSTV 


MDAS.REPL.HSSV 


MDAS_integer  Catalog  id#  of  some  action  listed  in 

MDAS.REPL.HSAV  for  a  data  set  replicate.  When 
inquiring  about  data  sets,  MDAS.REPL.HSA  may  be 
used  to  match  an  action  tracked  for  a  data  set 
replicate.  To  scan  or  set  MDAS_REPL_HSA  Info,  use 
MDAS.REPL.HSC  and  MDAS.REPL.HSAV. 

M  DAS  Time  Time  stamp  for  some  spectral  history  of  an  action  for  a 

data  set  replicate.  When  inquiring  about  data  sets, 
MDAS.REPL.HST  may  be  used  to  match  time  stamps 
of  spectral  history  compilations  for  actions  on  a  data 
set  replicate.  To  scan  or  set  MDAS.REPL.HST  Info, 
use  MDAS.REPL.HSC  and  MDAS.REPL.HSTV. 

MDAS-spectrun  Spectral  histories  of  an  action  for  a  data  set  replicate. 

When  inquiring  about  data  sets,  MDAS.REPL.HSS 
may  be  used  to  match  spectral  history  compilations  for 
arbitrary  actions  on  a  data  set  replicate.  To  scan  or  set 
MDAS.REPL.HSS  Info,  use  MDAS.REPL.HSC  and 
MDAS.REPL.HSSV. 

MDAS_integer  #  of  actions  listed  in  MDAS.REPL.HSAV, 

MDAS.REPL.HSTV,  and  MDAS.REPL.HSSV.  When 
inquiring  about  data  sets,  MDAS.REPL.HSC  may  be 
used  to  match  the  count  of  actions  tracked  to  date  for 
a  data  set  replicate.  When  scanning 
MDAS.REPL.HSC  from  data  set  Info  returned  by 
MDAS-INQUIREQ,  the  value  is  the  actual  count  for  a 
data  set  replicate.  When  adding  attributes  to  an  Info 
structure  for  Catalog  registration,  set 
MDAS.REPL.HSC  before  making  incremental  adds  of 
M  D  AS  .REP  L  _H  S  AV  or  MDAS.REPL.HSSV. 

MDAS .integer  Array  of  Catalog  id#’s  of  actions  data  set  replicate. 

array  When  inquiring  about  data  sets,  MDAS.REPL.HSAV 

may  be  used  to  match  a  set  of  actions  tracked  for  a 
data  set  replicate.  To  scan  MDAS.REPL.HSAV  Info, 
first  scan  MDAS.REPL.HSC  and  allocate  an  array  of 
that  size,  then  use  MDAS_INFO_SCAN_RATTR(L 
info,  MDAS.REPL.HSAV,  userarray,  status). 

MDAS  .time  Time  stamps  of  spectral  history  compilations  for  a 

array  data  set  replicate.  When  inquiring  about  data  sets, 

MDAS.REPL.HSTV  may  be  used  to  match  the  time 
stamp  array  for  spectral  history  compilations  on  a  data 
set  replicate.  To  scan  MDAS.REPL.HSTV  Info,  first 
scan  MDAS.REPL.HSC  and  allocate  an  array  of  that 
size,  then  use  MDAS _INFO_SCAN_RATTR(i,  info, 
MDAS.REPL.HSTV,  userarray,  status). 


MDAS_spectrum  Spectral  histories  for  a  data  set  replicate.  When 
array  inquiring  about  data  sets,  MDAS.REPL.HSSV  may  be 

used  to  match  entire  spectral  history  sets  a  data  set 
replicate.  To  scan  MDAS.REPL.HSSV  Info,  first  scan 
MDAS.REPL.HSC  and  allocate  an  array  of  that  size, 
then  use  MDAS JNFO JSC AN.RATTR (i  info, 
MDAS.REPL.HSSV’,  userarray,  status). 
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MDAS-DATASET  attribute 

Type 

Use 

(Replicate  Lock) 

MDAS-REPL-RLCK 

MDAS  Jogical 

Read  access  lock  flag  for  data  set  replicate  (all 
replicates  and  segments).  “True”  means  read  access  to 
data  set  is  locked. 

MDAS.REPL.RLCKS 

M  DAS -time 

Start  time  for  read  access  lock  flag  for  data  set 
replicate. 

MDAS.REPL.RLCKE 

MDAS -time 

End  time  for  read  access  lock  flag  for  data  set  replicate. 

MDAS.REPL.RLCKD 

MDAS  Jnteger 

Domain  Catalog  id#  which  is  allowed  to  set  read  locks 
on  data  set  replicate. 

MDAS-REPL-WLCK 

MDAS  Jogical 

Write  access  lock  flag  for  data  set  replicate.  “True” 
means  write  access  to  data  set  is  locked. 

MDAS.REPL.WLCKS 

MDAS -time 

Start  time  for  write  access  lock  flag  for  data  set 
replicate. 

MDAS.REPL.WLCKE 

MDAS  .time 

End  time  for  write  access  lock  flag  for  data  set 
replicate. 

MDAS-REPL.WLCKD 

MDAS  Jnteger 

Domain  Catalog  id#  which  is  allowed  to  set  read  locks 
on  data  set  replicate. 

MDAS-DATASET  attribute 

Type 

Use 

(Replicate  Security) 
MDAS-REPL-AUTK 

MDAS -string 

Public  authorization  key  for  data  set  replicate. 

MDAS.REPL.AUTM 

MDASJnteger 

Method  Catalog  id#  for  public  authorization  key. 

MDAS-REPL-RACCK 

MDAS  .string 

Public  read-access  key  for  data  set  replicate. 

MDAS-REPL-RACCM 

MDASJnteger 

Method  Catalog  id#  for  public  read-access  key. 

MDAS-REPL  _  WAC  C  K 

MDAS  .string 

Public  write- access  key  for  data  set  replicate. 

MDAS-R  EP  L_WA.CC  M 

MDASJnteger 

Method  Catalog  id#  for  public  write-access  key. 

MDAS-REPL.CRYK 

MDAS_string 

Public  encryption  key  for  data  set  replicate. 

MDAS-REPL  _C  RYM 

MDASJnteger 

Method  Catalog  id#  for  public  encryption  key. 

MDAS-DATASET  attribute 

Type 

Use 

(Replicate  Perf) 

MDAS-REPL.PERF 

TBD 

TBD. 
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MDAS.DATASET  attribute 

Type 

Use 

(Segment  Storage) 
MDASJtEPL_SEGC 

M  DAS  integer 

#  of  segments  in  individual  data  set  replication.  Any 
replication  may  be  partitioned.  Segments  are 
registered  as  independent  data  sets.  By  default,  all 
replications  are  composed  of  1  segment.  Use 
MDAS_INFO_SCAN_RATTR(z,  info, 
MDAS.REPL.SEGC,  replsegc,  status)  to  scan  this 
value  for  replicate  i.  Updates  made  to  individual 
segments  effect  the  parent  entity  according  to  the 
trigger  and  lineage  polices  of  the  parent  and  child  data 
sets. 

MDAS.REPL.SEGM 

MDAS_integer 

Catalog  id#  of  method  used  to  segment  some  data  set 
replicate.  Use  MDAS_INFO_SCAN_RATTR(i,  info, 
MDAS.REPL.SEGM,  replmeth,  status)  to  scan  this 
value  for  replicate  i. 

MDAS.REPL.SEGRV 

M  DAS  integer 
array 

Array  of  segment  ranks  for  Catalog  id#’s  listed  in 
MDAS.REPL.SEGIV.  These  ranks  provide  the  linkage 
between  MDAS.REPL.SEGIV  and 

MDAS.REPL.SEGM.  Use 

M D AS  J N FO _S C A N _R ATTR( 2 ,  info, 
MDAS.REPL.SEGRV,  replsegranks,  status)  to  scan 
this  value  for  replicate  i. 

MDAS.REPL.SEGIV 

M  DAS  integer 
array 

Array  of  data  set  Catalog  id#’s  composing  the 
segments  of  some  data  set  replicate.  Use 

M  D  AS  J  N  FO  _S  C  A  N  _R  ATTR(  i ,  info, 
MDAS.REPL.SEGIV,  replsegids,  status)  to  scan  this 
value  for  replicate  i. 

4. 7. 2*2. 2  MDAS  ^METHOD 


Methods  are  ultimately  stored  in  a  computing  environment  and  therefore  share  many  at¬ 
tributes  with  data  sets.  Here,  all  attributes  of  methods  are  listed  for  completeness.  De¬ 
scriptions  are  only  given  for  those  attributes  unique  to  methods. 

A  method  replicate  is  a  storage  instance  of  an  executable  code.  Hence,  method  replicates 
have  read,  write,  and  executable  attributes.  Replicates  of  the  same  method  instantiated 
for  different,  operating  systems  may  have  different  input,  output,  and  execution  parameter 
constraints. 

A  method  segment  is  a  physical  segment  of  an  executable  code  or  library.  Object  files 
composing  a  library  are  an  example  of  segments  of  an  executable  library  registered  as  a 
method. 

Methods  may  be  coupled  together  to  form  flows .  A  flow  is  a  compound  method  with 
specified  linkage  between  its  input/output  and  the  inputs/outputs  of  the  member  methods, 
plus  specific  internal  linkages  between  the  inputs  and  outputs  of  the  members. 

Unique  Method  Attributes 


63 


MDASJVIETHOD  attribute 

Type 

Use 

(Content  Variance) 

MDAS.METHJNVAR 

MDASJogicai 

Invariant  method  ^method  changes  format,  not 
content. 

MDAS.METHJVRTC 

MDASJnteger 

Invertible  method  — dnput  is  reproducible  from  output. 
MDAS.METH  JVRTC  is  the  count  of  registered 
methods  that  can  perform  this  inversion. 

MDAS.METHJVRTM 

MDASJnteger 

array 

If  MDAS-METHJVRT  is  greater  than  0,  then 
MDAS.METH  JVRTMm  is  the  Catalog  id#  of  a 
method  which  can  perform  output-to-input  inversion. 

MDAS.METHJVRTI 

MDASJnteger 

array 

For  each  method  m  in  MDAS.METHJVRTM, 
MDAS.METH  JVRTIm./c  maps  the  kth  output  of  the 
invertible  method  to  a  given  input  of 

MDAS.METH  JVRTMm.  MDASJVIETH JVRTI  has 
dimension  MDAS.METHJVRTC  by 
MDAS-METH.OUTC. 

MDAS.METHJVRTO 

M  DAS  .integer 
array 

i 

! 

For  each  method  m  in  MDAS.METHJVRTM, 
MDAS.METH  JVRTImA-  designates  which  output  of 
MDAS.METH  JVRTMm  will  reproduce  the  kth  input 
of  the  invertible  method.  MDAS.METHJVRTI  has 
dimension  MDAS.METH  JVRTC  by 

MDAS.METH  JNC. 

MDAS.METHOD  attribute 

Type 

Use 

(Server) 

MDAS.SERV.METH  | 

MDASJogicai  j 

i 

True  if  method  is  a  server.  See  MDAS.SERVER. 

MDAS.METHOD  attribute 

Type 

Use 

(Method  Lock) 

Additional  locking  attributes  for  methods. 

MDAS-METH.ELCK 

MDASJogicai 

Execute  access  lock  flag  for  logical  method  (all 
replicates  and  segments).  “True”  means  execute  access 
to  method  is  locked. 

MDAS.METH.ELCKS 

MDAS.time 

Start  time  for  execute  access  lock  flag  for  logical 
method  (all  replicates  and  segments). 

MDAS.METH.ELCKE 

MDAS-time 

End  time  for  execute  access  lock  flag  for  logical 
method  (all  replicates  and  segments). 

MDAS-METH.ELCK  D 

MDASJnteger 

Domain  Catalog  id#  which  is  allowed  to  set  execute 
locks  on  logical  method. 

M  DAS -METHOD  attribute 

Type 

Use 

(Method  Lock) 

Additional  locking  attributes  for  methods. 

MDAS.REPL.ELCK 

M  DAS -logical 

Execute  access  lock  flag  for  a  replicate  of  the  method. 
“True”  means  execute  access  to  method  is  locked. 

MDASJR.EPLJELCKS 

M  DAS -time 

Start  time  for  execute  access  lock  flag  for  a  replicate  of 
the  method. 

MDAS.REPL-ELCKE 

M  DAS -time 

End  time  for  execute  access  lock  flag  for  a  replicate  of 
the  method. 

MDAS_REPL_ELCKD 

MDAS-integer 

Domain  Catalog  id#  which  is  allowed  to  set  execute 
locks  on  a  replicate  of  the  method. 

MDAS-METHOD  attribute 

Type 

Use 

(Method  Security) 

Additional  security  attributes  for  methods. 

MDAS-STOR-EACCK 

M  DAS -string 

Execution-access  key  for  logical  method  (all  replicates). 

MDAS.STOR-EACCM 

MDAS_integer 

Execution-access  key  method  for  logical  method  (all 

replicates). 

MDAS_METHOD  attribute 

Type 

Use 

(Replicate  Security) 

Additional  security  attributes  for  methods. 

MDAS-REPL-EACCIv 

MDAS_string 

Execution- access  key  for  a  method  replicate  (single 

instance). 

MDAS-REPL-EACCM 

MDAS-integer 

Execution-access  key  method  for  a  method  replicate 

(single  instance). 
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MDAS.METHOD  attribute 

Type 

Use 

(Method  Inputs) 

MDASJVIETHJNC 

M  DAS  integer 

#  of  inputs  (data  set  inputs)  to  method.  May  be  used 
as  search  criteria  across  replicate  instances  of  methods. 

MDAS.METH.FIN 

M  DAS  integer 
array 

Format  Catalog  id#’s  of  inputs  to  method.  Dimension 
is  MDAS-METHJNC.  May  be  used  as  search  criteria 
across  replicate  instances  of  methods. 

MDAS.METH-DIN 

M  DAS  integer 
array 

Data  set  Catalog  id#’s  of  any  static  inputs  to  method. 
This  array  identifies  fixed  data  sets  that  must  be  used 
each  time  the  method  is  executed. 

MDAS_METH-DINj  =  NULL  indicates  no  fixed  data 
set  constraint  for  input  i.  Dimension  is 
MDAS-METHJNC.  May  be  used  as  search  criteria 
across  replicate  instances  of  methods. 

MDAS_METH_RIN 

MDASinteger 

array 

Resource  Catalog  id#5s  of  any  static  resource 
constraints  on  method  inputs.  This  array  identifies  any 
fixed  resources  that  must  be  used  with  particular 
inputs.  MDAS_METH_RIN;  =  NULL  indicates  no 
fixed  resource  constraint  for  input  i.  Dimension  is 
MDAS-METHJNC.  May  be  used  as  search  criteria 
across  replicate  instances  of  methods. 

MDAS.METH.UIN 

MDASinteger 

array 

User  Catalog  id#’s  of  any  static  user  constraints  on 
method  inputs.  This  array  identifies  any  fixed  users 
that  must  have  ownership  of  particular  inputs. 

M D A S _M ETH _RI N t  =  NULL  indicates  no  fixed  user 
constraint  for  input  i.  Dimension  is 

MDAS-METHJNC.  May  be  used  as  search  criteria 
across  replicate  instances  of  methods. 

MDASJVIETELPIN 

MDASinteger 

array 

The  rank  of  input  in  the  method  parameter 

specification  M D A S _M ETH _P A R A M .  Dimension  is 
MDAS-METHJNC.  May  be  used  as  search  criteria 
across  replicate  instances  of  methods. 
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MDAS.METHOD  attribute 

Type 

Use 

(Method  Repl.  Inputs) 
MDAS.REPLJNC 

M  DAS -integer 

#  of  inputs  (data  set  inputs)  to  method  instance. 

MDAS_REPL_FIN 

MDASJnteger 

array 

Format  Catalog  id#5s  of  inputs  to  method  instance. 
Dimension  is  MDAS-REPLJNC.  Array  for  replicate  r 
is  read  with  MDAS JNFO_SCAN_RATTR(). 

MDAS_REPL_DIN 

MDASJnteger 

array 

Data  set  Catalog  id#’s  of  any  static  inputs  to  method 
instance.  This  array  identifies  fixed  data  sets  that  must 
be  used  each  time  the  method  is  executed. 
MDAS-REPL_DINi  =  NULL  indicates  no  fixed  data 
set  constraint  for  input  i.  Dimension  is 
MDAS-REPLJNC.  Array  for  replicate  r  is  read  with 
MDAS_INFO_SCANJlATTR(). 

MDAS_REPL_RIN 

MDASJnteger 

array 

Resource  Catalog  id#’s  of  any  static  resource 
constraints  on  method  inputs.  This  array  identifies  any 
fixed  resources  that  must  be  used  with  particular 
inputs.  MDAS-REPL-RINj  =  NULL  indicates  no  fixed 
resource  constraint  for  input  i.  Dimension  is 
MDAS-REPLJNC.  Array  for  replicate  r  is  read  with 
!  MDAS_INFO_SCAN_RATTR(). 

MDAS-REPLJJIN 

MDASJnteger 

array 

User  Catalog  id#’s  of  any  static  user  constraints  on 
method  inputs.  This  array  identifies  any  fixed  users 
that  must  have  ownership  of  particular  inputs. 
MDAS_REPL_RINt-  =  NULL  indicates  no  fixed  user 
constraint  for  input  i.  Dimension  is 

MDAS-REPLJNC.  Array  for  replicate  r  is  read  with 
MDAS  _INFO_SCAN  Jl  ATTR( ) . 

MDASJIEPL-PIN 

MDASJnteger 

array 

The  rank  of  input  #i  in  the  method  parameter 
specification  MDAS _REPL_PARAM.  Dimension  is 
MDAS-REPLJNC.  Array  for  replicate  r  is  read  with 
MDAS_INFO-SCAN_RATTR(). 

MDAS.METHOD  attribute 

Type 

Use 

(Method  Outputs) 

MDASJVIETH-OUTC 

MDASJnteger 

#  of  outputs  (data  set  outputs)  from  method.  May  be 
used  as  search  criteria  across  replicate  instances  of 
methods. 

MDAS.METH-FOUT 

MDAS-integer 

array 

Format  Catalog  id#’s  of  outputs  from  method. 

Dimension  is  MDAS_METELOUTC.  May  be  used  as 
search  criteria  across  replicate  instances  of  methods. 

MDAS.METH.DOUT 

MDAS_integer 

array 

Data  set  Catalog  id#’s  of  any  static  outputs  from 
method.  This  array  identifies  fixed  data  sets  that  are 
reproduced  each  time  the  method  is  executed. 
MDAS_METH JDOUTt  =  NULL  indicates  no  fixed 
data  set  constraint  for  output  i.  Dimension  is 
MDAS_METH_OUTC.  May  be  used  as  search  criteria 
across  replicate  instances  of  methods. 

MDASJVIETHJROUT 

MDASJnteger 

array 

Resource  Catalog  id#’s  of  any  static  resource 
constraints  on  method  outputs.  This  array  identifies 
any  fixed  resources  that  must  be  used  with  particular 
outputs.  MDAS_METH_ROUTi  =  NULL  indicates  no 
fixed  resource  constraint  for  output  i.  Dimension  is 
MDAS_METH_OUTC.  May  be  used  as  search  criteria 
across  replicate  instances  of  methods. 

MDAS.METH.UOUT 

MDASJnteger 

array 

User  Catalog  id#’s  of  any  static  user  constraints  on 
method  outputs.  This  array  identifies  any  fixed  users 
that  must  have  ownership  of  particular  outputs. 
MDAS-METHJROUTi  =  NULL  indicates  no  fixed 
user  constraint  for  output  i.  Dimension  is 
MDAS_METH_OUTC.  May  be  used  as  search  criteria 
across  replicate  instances  of  methods. 

MDAS.METH.POUT 

MDASJnteger 

array 

The  rank  of  output  #i  in  the  method  parameter 
specification  MDAS_METH_PARAM.  Dimension  is 
MDAS_METH_OUTC.  May  be  used  as  search  criteria 
across  replicate  instances  of  methods. 
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MDAS.METHOD  attribute 

Type 

Use  1 

(Method  Repl.  Outputs) 
MDAS.REPL.OUTC 

MDAS_integer 

#  of  outputs  (data  set  outputs)  from  method.  Value 
for  replicate  r  is  read  with 

MDAS_INFOJ3CAN_RATTR(). 

MDAS.REPL.FOUT 

MDAS  Jnteger 
array 

Format  Catalog  id#’s  of  outputs  from  method. 
Dimension  is  MDAS.REPL.OUTC.  Array  for  replicate 
r  is  read  with  MDAS JNFO.SCAN_RATTR(). 

MDAS_REPL_DOUT 

MDAS  Jnteger 
array 

Data  set  Catalog  id#’s  of  any  static  outputs  from 
method.  This  array  identifies  fixed  data  sets  that  are 
reproduced  each  time  the  method  is  executed. 
MDAS-REPL  JDOUTi  =  NULL  indicates  no  fixed  data 
set  constraint  for  output  i.  Dimension  is 
MDAS.REPL.OUTC.  Array  for  replicate  r  is  read 
with  MDASJNFO_SCAN_RATTR(). 

MDAS.REPL.ROUT 

MDAS  Jnteger 
array 

Resource  Catalog  id^Us  of  any  static  resource 
constraints  on  method  outputs.  This  array  identifies 
any  fixed  resources  that  must  be  used  with  particular 
outputs.  MDAS.REPL.ROUT;  =  NULL  indicates  no 
fixed  resource  constraint  for  output  i.  Dimension  is 
MDAS.REPL.OUTC.  Array  for  replicate  r  is  read 
with  MDASJNFO_SCAN_RATTR(). 

MDAS.REPL.UOUT 

MDAS  Jnteger 
array 

User  Catalog  id#’s  of  any  static  user  constraints  on 
method  outputs.  This  array  identifies  any  fixed  users 
that  must  have  ownership  of  particular  outputs. 
MDAS.REPL.ROUT;  =  NULL  indicates  no  fixed  user 
constraint  for  output  i.  Dimension  is 
MDAS.REPL.OUTC.  Array  for  replicate  r  is  read 
with  MDASJNFO_SCAN_RATTR(). 

MDAS_REPL_POUT 

MDAS  Jnteger 
array 

The  rank  of  output  #i  in  the  method  parameter 
specification  MDAS.REPL.PARAM.  Dimension  is 
MDAS.REPL.OUTC.  Array  for  replicate  r  is  read 
with  MDASJNFO_SCAN_RATTR(). 
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MDAS.METHOD  attribute 

Type 

Use  1 

(Execution  Parameters) 
MDAS.METH-PTMPL 

M  DAS  .integer 

Parameter  template  for  method.  Utilizes  numeric 
dummy  variables  for  input  and  output  data  sets. 

Dummy  value  0  is  reserved  for  the  storage  name  of  the 
executable  in  the  spirit  of  Unix  argv[0].  All  other 
dummy  values  are  unique  and  greater  than  0. 
MDAS-METH-PIN  contains  the  mapping  of  listed 
inputs  to  dummy  values  for  inputs. 
MDAS-METH-POUT  contains  the  mapping  of  listed 
inputs  to  dummy  values  for  outputs.  NULL  values  in 
either  array  indicate  no  mapping.  Note  that 
MDAS-METH_PIN  and  MDAS-METH-POUT  are 
disjoint  with  the  possible  exception  of  NULL  values. 

May  be  used  as  search  criteria  across  replicate 
instances  of  methods. 

M  D  AS  _M  ET  H  -P  F  M  T 

M  DAS -integer 

Format  Catalog  id#  parameter  template.  May  be  used 
as  search  criteria  across  replicate  instances  of  methods. 

M  D  AS  JVI  ET  H  _P  M  ET  H 

M  DAS -integer 

Method  Catalog  id#  for  method  (or  MDAS  Library 
routine)  which  takes  MDAS-METH_PIN, 
MDAS_METH_POUT,  MDAS.METH-PTMPL, 
MDAS-STOR.DIR,  M DA S _STO R_N A M E ,  etc.  as 
input,  and  produces  a  parameter  stream  suitable  for 
MDAS-METH.EXECS.  May  be  used  as  search  criteria 
across  replicate  instances  of  methods. 

MDAS.METH.EXECS 

MDAS_integer 

Server  Catalog  id#  for  service  (or  MDAS  Library 
routine)  which  takes  output  of  MDAS_METH_PMETH 
and  executes  the  MDAS.METHOD.  May  be  used  as 
search  criteria  across  replicate  instances. 
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MDAS.METHOD  attribute 

Type 

Use 

(Repl.  Execution  Param’s) 
MDAS_REPL_PTMPL 

M  DAS -integer 

Parameter  template  for  method  instance.  Utilizes 
numeric  dummy  variables  for  input  and  output  data 
sets.  Dummy  value  0  is  reserved  for  the  storage  name 
of  the  executable  in  the  spirit  of  Unix  argv[0].  All 
other  dummy  values  are  unique  and  greater  than  0. 
MDAS_REPL_PIN  contains  the  mapping  of  listed 
inputs  to  dummy  values  for  inputs. 

MDAS_REPL_POUT  contains  the  mapping  of  listed 
inputs  to  dummy  values  for  outputs.  NULL  values  in 
either  array  indicate  no  mapping.  Note  that 
MDAS_REPL_PIN  and  MDAS_REPL_POUT  are 
disjoint  with  the  possible  exception  of  NULL  values. 
Value  for  replicate  r  is  read  with 
MDAS_INFO_SCAN_RATTR(). 

MDAS-REPL-PFMT 

MDAS_integer 

Format  Catalog  id#  parameter  template  for  method 
instance.  Value  for  replicate  r  is  read  with 
MDAS_INFO_SCAN-RATTR(). 

M  D  AS  _RE  P  L  _P  R  E  P  L 

MDASJnteger 

Method  Catalog  id#  for  method  (or  MDAS  Library- 
routine)  which  takes  MDAS.REPL  JPIN, 
MDAS-REPL.POUT,  MDAS.REPL.PTMPL, 
MDAS.REPL-DIR,  MDAS.REPL.NAME,  etc.  as 
input  and  produces  a  parameter  stream  suitable  for 
MDAS_REPL_EXECS.  Value  for  replicate  r  is  read 
with  MDASJNFO_SCAN_RATTR(). 

MDASJtEPL-EXECS 

MDAS  Jnteger 

Server  Catalog  id#  for  service  (or  MDAS  Library 
routine)  which  takes  output  of  MDAS_REPL_PREPL 
and  executes  the  MDAS.METHOD  instance.  Value  for 
replicate  r  is  read  with  MDAS _INFO_SCAN_RATTR(). 
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MDAS_METHOD  attribute 

Type 

Use 

(Method  Flow) 

Methods  may  be  coupled  together  to  form  flows .  A 
flow  is  a  compound  method  with  specified  linkage 
between  its  input/output  and  the  inputs/outputs  of 
the  member  methods,  plus  specific  internal  linkages 
between  the  inputs  and  outputs  of  the  members. 

M  D  AS_M  ETH  _F  L  0  W  C 

MDASJnteger 

#  of  methods  forming  flow.  May  be  used  as  search 
criteria  across  replicate  instances  of  methods. 

MDAS.METH.FLOVVM 

MDAS_integer 

array 

Method  Catalog  id#’s  of  flow  methods.  Dimension  is 
MDAS-METHJFLOWC.  May  be  used  as  search 
criteria  across  replicate  instances  of  methods. 

MDAS-METH-FLOWI 

MDASJnteger 

array 

Linkage  of  flow  inputs  to  each  method  input. 

Dimension  is  2  by  MDAS_METH_FLOWC.  If 
MDASJVIETH-FLOWUi  =  ro  and 
MDAS_METH_FLOWIi2  =  k  then  input  i  of  the  flow 
maps  to  input  k  of  flow  method  m.  May  be  used  as 
search  criteria  across  replicate  instances  of  methods. 

MDAS.METH.FLOWO 

MDASJnteger 

array 

Linkage  of  flow  outputs  to  each  method  output. 
Dimension  is  2  by  MDAS_METH_FLOYVC.  If 
MDASJVIETHJFLOWOji  =  rc  and 
MDAS.METHJFLOWOj2  =  m  then  input  j  of  the 
flow  maps  to  input  n  of  flow  method  m.  May  be  used 
as  search  criteria  across  replicate  instances  of  methods. 

MDAS.METH-FLOWE 

MDASJnteger 

matrix 

Execution  dependence  matrix.  Dimension  is 
MDAS-METHJ^LOWC  by  M  D  A  S  JVI ET H J7 L 0 W C .  If 
MDAS_METHJFL0WE5t  =  true  then  the  execution  of 
flow  method  s  depends  (in  some  unspecified  way)  on 
the  execution  of  flow  method  t.  If  false,  then  there  is  no 
dependency  of  s  on  t.  If  the  value  is  MDAS  JLECUR, 
then  s  has  recursive  dependencies  on  t.  Flows  with 
recursion  will  be  executed  at  least  two  times  until  a 
first  version  of  the  final  output (s)  defined  in 
MDASJVIETHJFLOWO  are  produced.  Note  that  input 
and  output  linkage  is  given  in  MDAS_METH_FLOWI 
and  MDAS_METH_FLOWO.  May  be  used  as  search 
criteria  across  replicate  instances  of  methods. 
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MDASJVIETHOD  attribute 

Type 

Use 

(Flow  Instances) 

Methods  may  be  coupled  together  to  form  flows.  A 
flow  is  a  compound  method  with  specified  linkage 
between  its  input /output  and  the  inputs/outputs  of 
the  member  methods,  plus  specific  internal  linkages 
between  the  inputs  and  outputs  of  the  members. 

MDAS_REPL_FLOWC 

MDAS  Jnteger 

#  of  methods  forming  flow.  Value  for  flow  replicate  r 
is  read  with  MDASJNFO_SCAN.RATTR(). 

MDAS_REPL_FLOWM 

MDAS  Jnteger 
array 

Method  Catalog  id#’s  and  replicate  #’s  of  flow 
instance  methods;  i.e.,  the  constituent  methods  of  a 
particular  flow  replicate.  Dimension  is  2  by 
MDAS_REPL_FLOWC.  MDAS  JlEPL_FLOWMzl  is 
flow  instance  method,  MDAS  JLEPL.FLOWM^  is 
specific  replicate  of  flow  instance  method.  Array  for 
flow  replicate  r  is  read  with 
MDASJNFO_SCANJlATTR(). 

MDAS_REPL_FLOWI 

MDAS  Jnteger 
array 

Linkage  of  flow  inputs  to  each  method  input. 

Dimension  is  3  by  MDAS  JLEPL  LFLOWC.  If 
MDAS_REPL_FLOWRi  =  m  and 
MDAS_REPL_FLOWI{2  =  k  then  input  i  of  the  flow 
maps  to  input  k  of  flow  method  m.  May  be  used  as 
search  criteria  across  replicate  instances  of  methods. 
Array  for  flow  replicate  r  is  read  with 
MDASJNFO_SCANJl  AT  T  R  ( ) . 

MD  AS  JREP  L  _F  L  0  WO 

MDAS  Jnteger 
array 

Linkage  of  flow  outputs  to  each  method  output. 
Dimension  is  2  by  MDAS_REPL_FLOVVC.  If 
MDAS_METH_FLOWO;i  =  n, 

MDAS_METH_FLOWO;2  =  m,  and 

M D AS _M ET H _F L 0 WO j 3  =  r  then  output  j  of  the 
flow  maps  to  output  n  of  replicate  r  of  flow  method  m. 
Array  for  flow  replicate  r  is  read  with 
MDASJNFO_SCANJRATTR(). 

MDAS_REPL_FLOWE 

MDAS  Jnteger 
matrix 

Execution  dependence  matrix.  Dimension  is 
MDAS_REPL_FLOWC  by  MDAS.REPL.FLOWC.  If 
MDAS_REPL_FLOWEsf  =  true  then  the  execution  of 
flow  method  -s  depends  (in  some  unspecified  way)  on 
the  execution  of  flow  method  t.  If  false,  then  there  is 
no  dependency  of  s  on  t.  If  the  value  is 

MDAS.RECUR,  then  s  has  recursive  dependencies  on 
t.  Flows  with  recursion  will  be  re-executed  until  the 
first  version(s)  of  the  final  output(s)  defined  in 
MDAS_REPL_FLOWO  are  produced.  Note  that  input- 
and  output  linkage  is  given  in  MDAS_REPL_FLOWI 
and  MDAS_REPL_FLOWO.  Array  for  flow  replicate  r 
is  read  with  MDAS JNFO_SCAN  JtATTRQ. 
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MDAS-METHOD  attribute 

Type 

Use 

(Intra-Flow  Linkage) 

Methods  may  be  coupled  together  to  form  flows.  A 
flow  is  a  compound  method  with  specified  linkage 
between  its  input/output  and  the  inputs/outputs  of 
the  member  methods,  plus  specific  internal  linkages 
between  the  inputs  and  outputs  of  the  members. 

MDAS-REPL.FLOWX 

MDAS_int,eger 
.  array 

For  each  MDAS_REPL_FLOWM,  the  #  of  inputs  with 
intra-flow  dependencies.  An  input  has  intra-flow 
dependency  if  it  requires  the  output  of  another  method 
in  the  flow.  MDAS-REPL.FLOWX*  is  the  #  of 
dependent  inputs  for  replicate 

MDAS-REPL-FLOWMi2  of  method 
MDAS_REPL_FLOWMii .  Array  for  flow  replicate  r  is 
read  with  MDAS JNFO.SCAN _RATTR(). 

M  D  AS  _REP  L  _F  L  0  W  U 

MDAS_integer 

array 

For  each  MDAS_REPL_FLOWM  dependent  input,  the 
dependent  output  and  method  #. 
MDAS-REPL-FLOWLRi  is  the  of  dependent  input  # 
in  method  i,  MDAS-REPL_FLOWU*2  is  the  flow 
method  instance  in  MDAS_REPL_FLOWM  on  which 
method  i  depends,  and  MDAS_REPL_FLOWU*3  is  the 
output  #  of  MDAS_REPL_FLOWUt2  which  input 
MDAS-REPL-FLOWUji  needs.  Array  for  flow 
replicate  r  is  read  with  MDAS _INFO_SCAN_RATTR(). 

MDAS_REPL_FLOWY 

M  DAS -integer 
array 

For  each  MDAS_REPL_FLOWM,  the  #  of  outputs 
with  intra-flow  dependencies.  An  output  has  intra-flow 
dependency  if  it  is  required  for  input  by  of  another 
method  in  the  flow.  MDAS-REPL_FLOWYt  is  the  # 
of  dependent  outputs  for  replicate 
MDAS_REPL_FLOWMi2  of  method 
MDAS-REPL-FLOWMa .  Array  for  flow  replicate  r  is 
read  with  MDAS_INFO_SCAN-RATTR( ). 

M  D  AS  JRE  P  L  _F  L  O  VV  V 

M  DAS  .integer 
array 

For  each  MDAS_REPL_FLOWM  dependent  output, 
the  dependent  input  and  method  #. 
MDAS-REPL_FLOWUti  is  the  #  of  the  dependent 
output  in  method  MDAS_REPL_FLOWU*2  is  the 
flow  method  instance  in  MDAS-REPL-FLOWM  which 
is  dependent  upon  method  i,  and 
MDAS_REPL_FLOWUi3  is  the  input  #  in 
MDAS_REPL_FLOWUi2  which  needs 
MDAS_REPL_FLOWUti .  Array  for  flow  replicate  r  is 
read  with  MDAS JNFO_SCAN_RATTR(). 

i\IDAS_REPL.FLOWZ 

MDAS -integer 
matrix 

Data  flow  dependence  matrix.  The  inputs  to  each 
method  in  MDAS_REPL_FLOWM  form  a  block  of 
rows  in  MDAS_REPL_FLOWZ,  there  are  a  total  of 

X  MDAS_REPL_FLOWXt  rows.  Similarly,  the  outputs 
of  each  flow  method  form  a  block  of  columns  and  there 
are  X  MDAS-REPL.FLOWY^  columns.  If 

M  D  AS  _RE  P  L  _F  LO  WXjj  =  MDAS -TRUE  then  output 
#j  is  linked  to  input  Matrix  values  are  otherwise 

false.  If  an  entire  column  is  false  and  the  corresponding 
output  data  set  is  new,  it  may  be  discarded.  Matrix  for 
flow  replicate  r  is  read  with 
MDAS_INFO_SCAN-RATTR(). 
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Shared  Attributes 


MDAS.METHOD  attribute 

Type 

Use 

(Base) 

M  DAS -NAME 

MDASJD 

MDAS.CDJD 

M  DAS  -string 

MDASJnteger 

MDAS_integer 

Methods  share  these  attributes  with  data  sets. 

MDAS.METHOD  attribute 

Type 

Use 

(Version) 

MDAS.VERSION 

MDAS-VERSIONX 

MDAS-VERSIONM 

MDAS-VERSIONP 

MDAS-VERSIONN 

MDAS_string 
MDASJogical 
MDAS  Jnteger 
MDAS  Jnteger 
'  MDAS  Jnteger 

Methods  share  these  attributes  with  data  sets. 

MDAS.METHOD  attribute 

Type 

Use 

(Alias) 

MDAS -ALIAS 

MDAS-ALIASC 

MDAS-ALIASV 

MDAS_string 
MDAS  Jnteger 
MDAS -string 
array 

Methods  share  these  attributes  with  data  sets. 

MDAS.METHOD  attribute 

Type 

Use 

(Documentation) 

MDAS.ABSTRACT 

MDAS.DOC 

MDAS  Jnteger 
MDASJnteger 

Methods  share  these  attributes  with  data  sets. 

MDAS.METHOD  attribute 

Type 

Use  H 

(SD) 

M  D  AS  _S  D  .TAB  L  E 

MDAS.SD.KEYC 

MDAS-SD-COLS 

MDAS.SD_KEY.TYP 

MDAS.SD.KEYS 

MDAS.SD_LOB.COL 

MDASJnteger 
MDASJnteger 
MDAS  .string 
array 

MDASJnteger 

MDAS.handle 

MDAS.string 

Methods  share  these  attributes  with  data  sets. 

MDAS.METHOD  attribute 

Type 

Use 

(Logical  Group) 

MDAS.STOR.GRPN 

MD  AS  _STO  R.G  RPI 
MDAS.STOR.GRPNC 
MDAS.STOR.GRPN  V 

MDAS.STOR.GRPIC 

MDAS.STOR.GRPIV 

MDAS_string 

MDASJnteger 

MDASJnteger 

MDAS.string 

array 

MDASJnteger 

MDASJnteger 

array 

Methods  share  these  attributes  with  data  sets. 
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MDASJVIETHOD  attribute 

Type 

Use 

(Logical  Domain) 

MDAS-STOR.DMNN 

MDAS-STORJDMNI 

MDAS.STORJDMNNC 

MDAS.STOR.DMNNV 

MDAS.STOR.DMNIC 

MDAS-STOR-DMNIV 

M  DAS  .string 
MDASinteger 
MDAS_integer 
M  DAS  .string 
array 

MDAS_integer 

MDASJnteger 

array 

Methods  share  these  attributes  with  data  sets. 

MDASJVIETHOD  attribute 

Type 

Use 

(Input  Lineage) 

MDASJ3TORJN 
MDASJSTORJNC 
MDAS-STOR  JNV 

MDASJnteger 
M  DAS -integer 
M  DAS -integer 
array 

Methods  share  these  attributes  with  data  sets. 

MDASJVIETHOD  attribute 

Type 

Use 

(Consequential  Lineage) 

MDAS-STOR.OUT 

MDAS-STOR.OUTC 

M  DAS  _ST  0  R-O  UT  V 

M  DAS -integer 
MDAS_integer 
MDASJnteger 
array 

Methods  share  these  attributes  with  data  sets. 

MDASJVIETHOD  attribute 

Type 

Use 

(Generation  Lineage) 

MDAS-STOR-GEN 

MDAS-STOR.GNP 

MDAS-STOR.GNR 

MDAS.STOR-GNU 

MDASJnteger 
MDAS_string 
MDASJnteger 
MDASJnteger  ; 

Methods  share  these  attributes  with  data  sets. 

MDAS.METHOD  attribute 

Type 

Use 

(Re-Generation  Policy) 

MDASJ3TOR.PLCY 

MDASJnteger 

Methods  share  these  attributes  with  data  sets. 

MDASJVIETHOD  attribute 

Type 

Use 

(Trigger) 

MDAS-STOR.TRGM 

MDAS.STOR.TRGP 

M  D  AS  -STO  R-T  RGC 
MDAS-STOR.TRGMV 

MDAS.STOR.TRGPV 

MDASJnteger 

MDASJnteger 

MDASJnteger 

MDASJnteger 

array 

MDASJnteger 

array 

Methods  share  these  attributes  with  data  sets. 
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MDAS.METHOD  attribute 

Type 

Use 

(Storage  Date) 

MDASJSTORJDATE 

M  DAS  .time 

Methods  share  these  attributes  with  data  sets. 

MDAS.METHOD  attribute 

Type 

Use 

(Storage  Permanence) 

MDASJSTOR.PERM 

MDAS_STOR_PURG 

MDAS.double 

MDASJogical 

Methods  share  these  attributes  with  data  sets. 

MDAS_METHOD  attribute 

Type 

Use 

(Storage  Size) 

MDAS.STOR.SIZE 

M  DAS  .size 

Methods  share  these  attributes  with  data  sets. 

M  DAS -METHOD  attribute 

Type 

Use 

(Storage  Format) 

MDAS.STOR.FMTN 

MDAS.STOR.FMTI 

MDAS_string 
MDAS  Jnteger 

Methods  share  these  attributes  with  data  sets. 

MDAS.METHOD  attribute 

Type 

Use 

(Storage  Resource) 

MDAS.STOR.RSCN 

MDAS.STOR.RSCI 

M  DAS  .string 
MDAS  Jnteger 

Methods  share  these  attributes  with  data  sets. 

MDAS.METHOD  attribute 

Type 

Use 

(Storage  Server) 

MDAS.STOR.SRVN 

MDAS.STOR.SRVT 

MDAS-string 

MDAS_integer 

Methods  share  these  attributes  with  data  sets. 

MDAS.METHOD  attribute 

Type 

Use 

(Storage  Path  and  Name) 

MDAS.STOR.DIR 

MDAS.STOR.NAM 

MDAS  .string 
MDAS-string 

Methods  share  these  attributes  with  data  sets. 

MDAS.METHOD  attribute 

Type 

Use 

(Method  Owner) 

MDAS.STOR.OWN 

MDAS  Jnteger 

Methods  share  these  attributes  with  data  sets. 

MDASJVIETHOD  attribute 

Type 

Use 

(Method  SpecHist) 

Methods  share  these  attributes  with  data  sets. 

MDAS_STOR_HSA 

MDAS_integer 

MDAS-STOR.HST 

M  DAS  .time 

MDAS-STOR.HSS 

MDAS-spectrur 

i 

MDAS-STOR-HSC 

M  DAS  -integer 

MDAS-STORJHSAV 

MDASJnteger 

array 

MDAS-STOR-HSTV 

MDAS.time 

array 

MDAS_STOR_HSSV 

MDAS-spectrur 

array 

i 

MDASJVIETHOD  attribute 

Type 

Use 

(Method  Perf) 

MDAS-STOR.PERF 

TBD 

Methods  share  these  attributes  with  data  sets. 

TBD. 

MDASJVIETHOD  attribute 

Type 

Use 

(Method  Lock) 

M  DAS  _ST  0  R-RLC  I\ 

MDAS-STOR.RLCKS 

MDAS.STOR-RLCKE 

MDAS.STOR.RLCKD 

MDAS_STOR_WLCIv 

MDAS-STOR.VVLCKS 

MDAS.STOR.WLCKE 

MDAS-STOR.WLCKD 

MDASJogical 

MDAS-time 

M  DAS -time 

MDASJnteger 

MDASJogical 

MDAS.time 

MDAS-time 

MDASJnteger 

Methods  share  these  attributes  with  data  sets. 

MDAS.METHOD  attribute 

Type 

Use 

(Method  Security) 

MDAS.STOR-AUTK 

MDAS-STOR.AUTM 

MDAS.STOR.RACCK 

MDAS.STOR-RACCM 

MDAS.STOR-VVACCK 

MDAS-STOR-WACCM 

MDAS-STORX'RYK 

MDAS.STOR.CRYM 

M  DAS  .string 
MDASJnteger 
M  DAS -string 

M  DAS -integer 
M  DAS  .string 
MDASJnteger 
M  DAS  .string 
MDASJnteger 

Methods  share  these  attributes  with  data  sets. 

MDASJVIETHOD  attribute 

Type 

Use 

( Replicates) 

MDAS-REPLICATES 

MDASJnteger 

Methods  share  these  attributes  with  data  sets. 

M  DAS  .METHOD  attribute 

Type 

Use  ] 

(Replicate  Group) 

Methods  share  these  attributes  with  data  sets. 

MDAS-REPL.GRPN 

MDAS_string 

M  D  AS  _RE  P  L  -GRP  N  C 

MDAS  -integer 

MDAS.REPL-GRPNV 

array 

MDAS-string 

MDAS.REPL-GRPI 

MDAS-REPL-GRPIC 

array 

MDAS  -integer 
MDAS  -integer 

MDAS-REPL-GRPIV 

array 

MDAS_string 

array 

MDAS-METHOD  attribute 

Type 

Use 

(Replicate  Domain) 

Methods  share  these  attributes  with  data  sets. 

MDAS-REPL-DMNN 

MDAS-string 

MDAS-REPL.DMNNC 

MDAS  -integer 
array 

MDAS.REPL.DMNNV 

MDAS_string 

array 

M  DAS  _RE  P  L  -D  M  N I 

MDAS_integer 

M  D  AS  _RE  P  L  _D  M  NIC 

MDAS  Jnteger 
array 

MDAS-REPL-DMNIV 

MDAS-string 

array 

MDAS_METHOD  attribute 

Type 

Use  ~ 

(Repl.  Input  Lineage) 

MDAS-REPLJN 
MDAS.REPLJNC 
MDAS_REPLJN  V 

MDAS  Jnteger 
MDAS  Jnteger 
MDAS  Jnteger 
array 

Methods  share  these  attributes  with  data  sets. 

MDAS.METHOD  attribute 

Type 

Use 

(Repl.  Conseq.  Lineage) 

MDAS_REPL_OUT 

MDAS-REPL.OUTVC 

MDAS-REPL-OUTV 

MDAS  Jnteger 
MDAS  Jnteger 
MDAS  Jnteger 
array 

Methods  share  these  attributes  with  data  sets. 

MDAS-METHOD  attribute 

Type 

Use 

(Repl.  Gen.  Lineage) 

M  D  AS  _REP  L-G  EN 
MDAS-REPL.GNP 
MDAS_REPL_GNR 
MDAS-REPL.GNU 

MDAS  Jnteger 
MDAS-string 
MDAS  Jnteger 
MDAS  Jnteger 

Methods  share  these  attributes  with  data  sets. 
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MDAS.METHOD  attribute 

Type 

Use 

(Replication  Trigger) 

MDAS.REPL-TRGM 

MDAS.REPL.TRGP 

MDAS.REPL.TRGC 

MDAS.REPL.TRGMV 

MDAS.REPL.TRGPV 

MDAS_integer 

MDASJnteger 

MDASJnteger 

MDASJnteger 

array 

MDASJnteger 

array 

Methods  share  these  attributes  with  data  sets. 

MDAS.METHOD  attribute 

Type 

Use 

(Repl.  Re-Gen.  Policy) 

MDAS.REPL.PLCY 

MDASJnteger 

Methods  share  these  attributes  with  data  sets. 

MDAS.METHOD  attribute 

Type 

Use 

(Replicate  Dates) 

MDAS.REPL.DATE 

MDAS.REPL.DATEV 

M  DAS  .time 

M  DAS  .time 

array 

Methods  share  these  attributes  with  data  sets. 

MDAS.METHOD  attribute 

Type 

Use 

(Replicate  Permanence) 

MDAS.REPL.PERM 

MDAS.REPL.PERMV 

MDAS.REPL.PURG 

MDAS.REPL.PURGV 

M  DAS  .double 

M  DAS  .double 

array 

MDASJogical 

MDASJogical 

array 

Methods  share  these  attributes  with  data  sets. 

MDAS.METHOD  attribute 

Type 

Use 

(Replicate  Sizes) 

MDAS.REPL.SIZE 

MDAS.REPL.SIZEV 

M  DAS  .size 

M  DAS. size 

array 

Methods  share  these  attributes  with  data  sets. 
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M  DAS  .METHOD  attribute 

Type 

Use 

(Replicate  Format) 

Methods  share  these  attributes  with  data  sets. 

MDAS_REPL_FMTH 

MDAS  -logical 

Note:  a  method  replicate 
with  heterogeneous  format 
segments  will  not  have  any 
data  in  the  format 
attributes  below.  See 

MDAS-REPLJ3EGC. 

MDAS-REPL.FMTN 

MDAS_REPL_FMTNV 

MDAS_REPL_FMTI 

MDAS-REPL-FMTIV 

M  DAS  .string 
MDAS  .string 
array 

MDAS_integer 
MDAS -integer 
array 

MDAS-METHOD  attribute 

Type 

Use 

(Repl.  Storage  Resource  ) 

Methods  share  these  attributes  with  data  sets. 

MDAS-REPL.RSCH 

MDAS  Jogical 

Note:  a  method  replicate 
with  distributed  storage 
segments  will  not  have  any 
data  in  the  resource 
attributes  below.  See 
MDAS-REPL-SEC4C. 

MDAS-REPL-RSCN 

MDAS-REPL-RSCNV 

MDAS_string 

MDAS_string 

MDAS-REPL.RSCI 

MDAS-REPL-RSCIV 

array 

'  MDASJnteger 
MDAS  .integer 
array 

MDAS-METHOD  attribute 

Type 

Use 

(Repl.  Storage  Server  ) 

Methods  share  these  attributes  with  data  sets. 

MDAS-REPL.SRVH 

MDAS  Jogical 

Note:  a  method  replicate 
with  heterogeneous 
storage  service  segments 
will  not  have  anv  data  in 
the  server  attributes 
below.  See 

MDAS-REPL-SEGC. 

MDAS-REPL-SRVN 

MDAS-REPL-SRVNV 

MDAS  .string 

1  MDAS-string 

MDAS-REPL.SRVI 

MDAS-REPL-SRVIV 

array 

MDASJnteger 

MDASJnteger 

array 
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MDAS.METHOD  attribute 

Type 

Use 

(Repl.  Dir.  and  Name  ) 

Methods  share  these  attributes  with  data  sets. 

Note:  a  method  replicate 
with  heterogeneous 
storage  segments  will  not 
have  any  data  in  the 
directory  and  name 
attributes  below.  See 
MDAS.REPL.SEGC. 

MDAS.REPL-DIRN 

M  D  AS  _RE  P  L  _DI  RN  V 

MDAS_string 

MDAS-string 

M  D  AS  _RE  P  L  _N  A  M  N 

M  DAS  -RE  P  L  _N  AM  N  V 

array 

MDAS-string 

MDAS-string 

array 

MDAS.METHOD  attribute 

Type 

Use 

(Replicate  Owner  ) 

M  DAS  -REPL  _OWN 

M  D  AS  _RE  P  L  _0  W  N  V 

M  DAS  .string 
MDAS-string 
array 

Methods  share  these  attributes  with  data  sets. 

MDAS.METHOD  attribute 

Type 

Use 

(Replicate  SpecHist) 

MDAS.REPL.HSA 

MDAS_REPL_HST 

MDAS_REPL_HSS 

MDAS-REPL.HSC 

M  D  A  S  _RE  P  L  _H  S  AV 

M  D  A  S  _RE  P  L  _H  ST  V 

MDAS-REPL.HSSV 

M  DAS  .integer 
M  DAS -time 

M  DAS -spec  trur 
M  DAS  -integer 
M  DAS  -integer 
array 

MDAS_time 

array 

MDAS_spectriir 

array 

Methods  share  these  attributes  with  data  sets. 

1 

i 

MDAS.METHOD  attribute 

Type 

Use 

(Replicate  Lock) 

MDAS-REPL.RLCK 

MDAS.REPL.RLCKS 

MDAS.REPL.RLCKE 

MDAS.REPL-RLCKD 

MDAS.REPL.WLCK 

MDAS-REPL.WLCKS 

MDAS.REPL.WLCKE 

MDAS-REPL.WLCKD 

M  DAS -logical 

MDAS.time 

MDAS-time 

M  DAS -integer 
M  DAS -logical 
MDAS_time 
MDAS-time 
MDASJnteger 

Methods  share  these  attributes  with  data  sets. 

82 


MDAS-METHOD  attribute 

Type 

Use 

(Replicate  Security) 

M  DAS  _R  EPL-AUTK 

MDAS_REPL_AUTM 

MDAS.REPL.RACCK 

MDAS.REPL.RACCM 

MDAS.REPL.WACCK 

MDAS.REPL.WACCM 

MDAS-REPL-CRYK 

M  D  AS  _R  E  P  L  _C  RYM 

M  DAS  ^string 

M  DAS  integer 
MDAS_string 
MDAS_integer 
M  DAS  .string 
.  M  DAS  integer 
M  DAS  .string 
MDASinteger 

Methods  share  these  attributes  with  data  sets. 

MDAS-METHOD  attribute 

Type 

Use 

(Replicate  Perf) 

MDAS-REPL.PERF 

TBD 

Methods  share  these  attributes  with  data  sets. 

TBD. 

MDAS-METHOD  attribute 

Type 

Use 

(Segment  Storage) 

MDAS-REPL.SEGC 

MDAS-REPL-SEGM 

MDAS-REPL-SEGRV 

MDAS_REPL_SEGIV 

MDASinteger 

MDASinteger 

MDASinteger 

array 

MDASinteger 

array 

Methods  share  these  attributes  with  data  sets. 

4.7.2. 2.3  MDAS -RESOURCE 


Resources  share  many  attributes  with  data  sets  and  methods.  Since  resources  are  not 
truly  “stored',  the  prefix  MDAS_ST0R_  is  redefined  to  MDAS_RSRC  for  resources.  Further, 
resources  are  not  considered  to  be  replicable.  To  identify  resources  with  similar  (or  identical) 
characteristics,  define  a  group  and  give  the  resources  membership  in  that  group. 

Here,  all  attributes  of  resources  are  listed  for  completeness.  Descriptions  are  only  given  for 
those  attributes  unique  to  resources. 

A  resource  location  is  a  description  of  its  network  address  and  physical  local. 

A  resource  segment  is  a  physical  component  (e.g.,  peripheral)  of  a  compound  computer 
system. 

Unique  Resource  Attributes 


MDAS-RESOURCE  attribute 

Type 

Use 

(Resource  Location) 
MDAS-RSRC-LOC 

TBD 

TBD. 
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MDAS.RESOURCE  attribute 

Type 

Use 

(Resource  Services) 
MDAS.RSRC-SRVI 

M  DAS  integer 

Catalog  id#  of  some  available  server. 

MDAS.RSRC.SRVN 

MDASinteger 

Name  or  alias  of  some  available  server. 

MDAS.RSRC.SRVC 

M  DAS  integer 

#  of  services  available. 

M  D  AS  _RS  RC  _S  RVI V 

MDASinteger 

Catalog  id#5s  of  available  servers. 

MDAS_RSRC_SRVNV 

array 

MDAS_string 

Names  of  available  servers. 

array 

Shared  Attributes 


MDAS-RESOURCE  attribute 

Type 

Use 

(Base) 

Resources  share  these  attributes  with  data  sets. 

M  DAS -NAME 

M  DAS  .string 

M  DAS -ID 

MDASinteger 

MDAS-CD-ID 

MDASinteger 

MDAS.RESOURCE  attribute 

Type 

Use 

(Version) 

MDAS.VERSION 

MDAS.VERSIONX 

MDAS.VERSIONM 

MDAS.VERSIONP 

MDAS.VERSIONN 

MDAS^tring 

MDASiogical 

MDASinteger 

MDASinteger 

MDASinteger 

Resources  share  these  attributes  with  data  sets. 

MDAS-RESOURCE  attribute 

Type 

Use 

( Alias ) 

Resources  share  these  attributes  with  data  sets. 

M  DAS -ALIAS 

MDAS_string 

MDAS.ALIASC 

MDASinteger 

MDAS-ALIASV 

MDASjstring 

array 

MDAS-RESOURCE  attribute 

Type 

Use 

(Documentation) 

M  D  AS  _A  BSTRACT 

M  DAS -DOC 

MDASinteger 

MDASinteger 

Resources  share  these  attributes  with  data  sets. 
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MDAS-RESOURCE  attribute 

Type 

Use 

(Logical  Group) 

MDAS-RSRC-GRPN 

MDAS_RSRC_GRPI 

MDAS_RSRC_GRPNC 

MDAS_RSRC_GRPNV 

MDAS.RSRC.GRPIC 

MDAS_RSRC_GRPIV 

MDASjstring 

M  DAS -integer 
MDASJnteger 
MDAS_string 
array 

MDASJnteger 

MDASJnteger 

array 

Resources  share  these  attributes  with  data  sets. 

MDAS.RESOURCE  attribute 

Type 

Use 

(Logical  Domain) 

MDAS-RSRC-DMNN 
MDAS.RSRC.DMNI 
MDAS.RSRC.DMNNC 
MDAS_RSRC_DMNN  V 

MDAS_RSRC_DMNiC 

MDAS-RSRC-DMNIV 

M  DAS -string 

MDASJnteger 

MDASJnteger 

MDAS_string 

array 

MDASJnteger 

MDASJnteger 

array 

Resources  share  these  attributes  with  data  sets. 

M  DAS -RESOURCE  attribute 

Type 

Use 

(Trigger) 

MDAS-RSRC-TRGM 
MDAS-RSRC-TRGP 
MDAS_RSRC_TRGC 
MDAS-RSRC_TRGM  V 

MDAS-RSRC-TRGPV 

MDASJnteger 

MDASJnteger 

MDASJnteger 

MDASJnteger 

array 

MDASJnteger 

array 

Resources  share  these  attributes  with  data  sets. 

MDAS -RESOURCE  attribute 

Type 

Use 

(Instantiation  Date) 

MDAS-RSRC.DATE 

MDAS -time 

Resources  share  these  attributes  with  data  sets. 

MDAS-RESOURCE  attribute 

Type 

Use 

(Resource  Format) 

MDAS.RSRC-FMTN 

MDAS-RSRC-FMTI 

MDAS_string 

MDASJnteger 

Resources  share  these  attributes  with  data  sets. 

MDAS-RESOURCE  attribute 

Type 

lTse 

(Resource  Owner) 

MDAS-RSRC.OWN 

MDASJnteger 

Resources  share  these  attributes  with  data  sets. 
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MDAS.RESOURCE  attribute 

Type 

Use 

(Resource  SpecHist) 

MDAS.RSRC.HSA 

MDAS_RSRC_HST 

MDAS.RSRC.HSS 

M  D  A  S  _RS  RC  _H  S  C 

M  D  A  S  _RS  RC  _H  S  AV 

MDAS_RSRC_HSTV 

MDAS_RSRC_HSSV 

MDASJnteger 

MDAS.time 

MDAS_spectrur 

MDASJnteger 

MDASJnteger 

array 

MDAS.time 

array 

M  DAS  .spectrur 
array 

Resources  share  these  attributes  with  data  sets. 

i 

i 

MDAS.RESOURCE  attribute 

Type 

Use 

(Resource  Perf) 

MDAS.RSRC.PERF 

TBD 

Resources  share  these  attributes  with  data  sets. 

TBD. 

MDAS.RESOURCE  attribute 

Type 

Use 

(Resource  Lock) 

Resources  share  these  attributes  with  data  sets  and 
methods. 

M  D  AS  _RS  RC  _RLC  K 

MDASJogical 

M  D  AS  _RS  RC  _RLC  K  S 

MDAS.time 

MDAS_RSRC_RLCKE 

MDAS.time 

MDAS_RSRC_RLCKD 

MDASJnteger 

M  D  AS  _RS  RC  _W  L  C  K 

MDASJogical 

MDAS.RSRC.WLCKS 

MDAS.time 

M  DAS  _RS  RC  _  W  L  C  K  E 

MDAS.time 

MDAS.RSRC.WLCKD 

MDASJnteger 

MDAS.RSRC.ELCK 

MDASJogical 

MDAS.RSRC.ELCKS 

MDAS.time 

MDAS_RSRC_ELCKE 

MDAS.time 

MDAS.RSRC.ELCKD 

MDASJnteger 

MDAS.RESOURCE  attribute 

Type 

Use 

(Resource  Security) 

MDAS.RSRC.AUTK 
MDAS.RSRC.AUTM 
MDAS.RSRC.RACCK 
MDAS.RSRC.RACCM 
MDAS.RS  RC  _WAC  C  K 

M  D  AS.RS  RC.WACC  M 

MDAS.RSRC.EACCK 

MDAS.RSRC.EACCM 

MDAS.RSRC.CRYK 

MDAS.RSRC.CRYM 

M  DAS  .string 

MDASJnteger 

M  DAS  .string 

MDASJnteger 

MDAS.string 

MDASJnteger 

MDAS_string 

MDASJnteger 

MDAS-st.ring 

MDASJnteger 

Resources  share  these  attributes  with  data  sets  and 
methods. 
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MDAS.RESOURCE  attribute 

Type 

Use 

(Resource  Segments) 

MDAS-RSRC.SEGC 

MDAS_RSRC_SEGM 

MDAS-RSRC-SEGRV 

M  D  A  S  _RS  RC  _S  E  G I V 

MDASJnteger 

MDASJnteger 

MDASJnteger 

array 

M  DAS -integer 
array 

Resources  share  these  attributes  with  data  sets. 

4. 7.2. 2.4  MDASJJSER 

A  user  is  the  owner  of  a  data  set,  method,  resource,  or  process.  User  accounts  are  in¬ 
stantiated  by  a  system  administrator  and  gain  access  to  resources  through  membership  in 
security  domains.  An  individual  (human)  with  multiple  accounts  is  considered  a  single  user 
with  replicate  accounts.  Each  replicate  can  have  separable  access  characteristics  through 
individual  domain  attributes.  To  identify  users  with  similar  (or  identical)  characteristics, 
users  membership  in  a  group  or  domain. 

User  metadata  have  some  attributes  common  to  data  sets  and  methods,  but  are  not  parti¬ 
tioned  into  segments.  Here,  all  attributes  of  users  are  listed  for  completeness.  Descriptions 
are  only  given  for  those  attributes  unique  to  users. 

Unique  User  Attributes 

TBD. 

Shared  Attributes 


MDAS-USER  attribute 

Type 

Use 

(Account  Lock) 

Users  share  these  attributes  with  other  entities. 

MDAS_USER_ELCK 

MDASJogical 

Users  share  these  attributes  with  other  entities. 

MDAS_USER.ELCKS 

MDAS_time 

Users  share  these  attributes  with  other  entities. 

MDAS-USER-ELCKE 

M  DAS  -time 

Users  share  these  attributes  with  other  entities. 

MDAS-USER.ELCKD 

MDAS_integer 

Users  share  these  attributes  with  other  entities. 

MDAS-USER  attribute 

Type 

Use 

(Account  Lock) 

Users  share  these  attributes  with  other  entities. 

MDAS_REPL_ELCK 

MDASJogical 

Users  share  these  attributes  with  other  entities. 

MDAS_REPL_ELCKS 

M  DAS -time 

Users  share  these  attributes  with  other  entities. 

MDAS-REPL.ELCKE 

MDAS.time 

Users  share  these  attributes  with  other  entities. 

MDAS-REPL-ELCKD 

MDAS  -integer 

Lasers  share  these  attributes  with  other  entities. 
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MDAS-USER  attribute 

Type 

Use 

(Account  Security) 

MDAS-STOR-EACCK 

MDAS_STOR_EACCA 

MDAS_string 

!  MDASJnteger 

Users  share  these  attributes  with  other  entities. 

Users  share  these  attributes  with  other  entities. 

Users  share  these  attributes  with  other  entities. 

MDAS-USER  attribute 

Type 

Use 

(Replicate  Security) 

MDAS.REPL.EACCK 

MDAS-REPLJEACCM 

MDAS_string 

MDASJnteger 

Users  share  these  attributes  with  other  entities. 

Users  share  these  attributes  with  other  entities. 

Users  share  these  attributes  with  other  entities. 

MDAS-USER  attribute 

Type 

Use 

(Base) 

Users  share  these  attributes  with  other  entities. 

MDAS.NAME 

MDAS_string 

MDASJD 

MDASJnteger 

MDAS-CDJD 

MDASJnteger 

MDAS_USER  attribute 

Type 

Use 

(Version) 

MDAS-VERSION 

M  D  AS_V  E  RS 10  NX 
MDAS-VERSIONM 
MDAS-VERSIONP 
MDAS-VERSIONN 

M  DAS  jst.  ring 

MDASJogical 

MDASJnteger 

MDASJnteger 

MDASJnteger 

Users  share  these  attributes  with  other  entities. 

MDAS_USER  attribute 

Type 

Use 

(Alias) 

MDAS.ALIAS 

MDAS-ALIASC 

MDAS-ALIASV 

MDAS_string 

MDASJnteger 

MDAS_string 

array 

Users  share  these  attributes  with  other  entities. 

MDAS-USER  attribute 

Type 

Use 

(Documentation) 

MDAS-ABSTRACT 

MDAS.DOC 

MDASJnteger 

MDASJnteger 

Users  share  these  attributes  with  other  entities. 
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MDAS-USER  attribute 

Type 

Use 

(SD) 

MDAS.SD.TABLE 

MDAS.SD.KEYC 

MDAS_SD.COLS 

MDAS_SD_KEY_TYP 

MDAS_SD_KEYS 

MDAS-SD.LOB-COL 

MDASJnteger 

MDASJnteger 

MDASjstring 

array 

MDASJnteger 
MDASJiandle 
:  M  DAS  .string 

Users  share  these  attributes  with  other  entities. 

MDAS-USER  attribute 

Type 

Use 

(Logical  Group) 

MDAS.STOR.GRPN 
M  D  A  S  _S  T  0  R  -G  RP I 
MDAS.STOR.GRPNC 
MDAS_STOR_GRPN\ 

MDAS-STOR-GRPIC 

MDAS_STOR_GRPIV 

MDAS-string 

MDASJnteger 

MDASJnteger 

MDAS_string 

array 

MDASJnteger 

MDASJnteger 

array 

Users  share  these  attributes  with  other  entities. 

MDAS.USER  attribute 

Type 

Use 

(Logical  Domain) 

MDAS-STOR-DMNN 

MDAS-STOR.DMNI 

M  D  A  S  _S  TO  R  _DM  N  X  ( 
MDAS_STOR_DMNN^ 

MDAS-STOR.DMNIC 

MDAS-STOR.DMNIV 

MDAS-string 
MDASJnteger 
''  MDASJnteger 

7  MDAS-string 
array 

MDASJnteger 

MDASJnteger 

array 

Lasers  share  these  attributes  with  other  entities. 

MDAS-USER  attribute 

Type 

L'se 

(Input  Lineage) 

MDAS-STORJN 

MDAS.STOR.INC 

MDAS-STOR-INV 

MDASJnteger 

MDASJnteger 

MDASJnteger 

array 

Users  share  these  attributes  with  other  entities. 

MDAS-USER  attribute 

Type 

Use 

(Consequential  Lineage) 

MDAS-STOR-OUT 

MDAS-STOR-OUTC 

MDAS-STOR-OUTV 

MDASJnteger 

MDASJnteger 

MDASJnteger 

array 

Users  share  these  attributes  with  other  entities. 
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MDAS-USER  attribute 

Type 

Use 

(Generation  Lineage) 

MDASJ3TOR-GEN 

MDAS-STOR.GNP 

MDAS.STOR-GNR 

MDAS_STOR_GNU 

MDASinteger 
MDAS-string 
MDASinteger 
M  DAS  integer 

Users  share  these  attributes  with  other  entities. 

MDAS-USER  attribute 

Type 

Use 

(Re-Generation  Policy) 

MDAS-STOR.PLCY 

MDASinteger  ! 

Users  share  these  attributes  with  other  entities. 

MDAS-USER  attribute 

Type 

Use 

(Trigger) 

MDAS-STOR-TRGM 

MDAS-STOR.TRGP 

MDAS.STOR.TRGC 

MDASjSTOR.TRGM\ 

MDAS-STOR.TRGPV 

MDASinteger 

MDASinteger 

MDASinteger 

T  MDASinteger 
array 

MDASinteger 

array 

Users  share  these  attributes  with  other  entities. 

MDAS-USER  attribute 

Type 

Use 

(Storage  Date) 

M  DAS  .ST  O  R  -DAT  E 

MDAS_time 

Users  share  these  attributes  with  other  entities. 

MDAS-USER  attribute 

Type 

Use 

(Storage  Permanence) 

MDAS-STOR.PERM  ! 
MDAS-STOR.PURG 

MDAS_double 

MDASiogical 

Users  share  these  attributes  with  other  entities. 

MDAS-USER  attribute 

Type 

Use 

(Storage  Format) 

MDAS-STOR.FMTN 

MDAS-STOR.FMTI 

MDAS_string 

MDASinteger 

Users  share  these  attributes  with  other  entities. 

MDAS-USER  attribute 

Type 

Use 

(Storage  Resource) 

MDAS-STOR-RSCN 

MDAS-STOR-RSCI 

MDAS_string 

MDASinteger 

Users  share  these  attributes  with  other  entities. 

MDAS-USER  attribute 

Type 

Use 

(Storage  Server) 

MDAS-STOR.SRVN 

MDAS-STOR.SRVI 

MDAS_string 

MDASinteger 

Users  share  these  attributes  with  other  entities. 
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MDAS-USER  attribute 

Type 

Use 

(Storage  Path  and  Name) 

MDAS-STOR.DIR 

MDAS.STOR.NAM 

M  DAS  jst  ring 
MDASjstring 

Users  share  these  attributes  with  other  entities. 

MDAS-USER  attribute 

Type 

Use 

(Account  Admin.) 

MDAS.STOR.OWN 

MDAS_integer 

Users  share  these  attributes  with  other  entities. 

MDAS-USER  attribute 

Type 

Use 

(User  SpecHist) 

Users  share  these  attributes  with  other  entities. 

MDAS.STOR.HSA 

MDASJnteger 

MDAS_STOR_HST 

M  DAS -time 

MDASJSTOR.HSS 

MDAS_spectrur 

1 

MDASJ5TOR.HSC 

MDAS-integer 

M  D  AS  _STO  R_H  S  AV 

MDASJnteger 

array 

MDAS_STOR_HSTV 

MDAS_time 

array 

MDAS_STOR_HSSV 

MDAS-spectrur 

array 

MDAS.USER  attribute 

Type 

Use 

(User  Perf) 

MDAS_STOR_PERF 

TBD 

Users  share  these  attributes  with  other  entities. 

TBD. 

MDAS-USER  attribute 

Type 

Use 

(User  Lock) 

MDAS-STOR-RLCK 

MDAS-STOR.RLCKS 

MDAS.STOR-RLCKE 

MDAS.STOR-RLCKD 

MDAS.STOR.WLCK 

MDAS-STOR.WLCKS 

MDAS_STOR_WLCKi 

MDAS_STOR_WLCKI 

MDASJogical 

AID  AS -time 

MDAS-time 

MDASJnteger 

MDASJogical 

MDAS_time 

L  MDAS-time 
j)  MDASJnteger 

Users  share  these  attributes  with  other  entities. 

MDAS.USER  attribute 

Type 

Lise 

(User  Security) 

MDAS-STOR-AUTK 
MDAS-STOR.AUTM 
MDAS-STOR-RACCK 
M  DA  S  _ST  0  R-R  ACC  A: 
AIDAS-STOR-WACCI; 
AIDAS-STOR  -  WAC  C  3 
MDAS-STOR.CRYK 
MDAS-STOR-CRYM 

MDAS_string 
AIDAS  Jnteger 
MDAS_string 
[  MDASJnteger 
l  MDASjstring 

I  AID  AS  Jnteger 
AIDAS-string 
AIDASJnteger 

Lasers  share  these  attributes  with  other  entities. 
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MDAS-USER  attribute 

Type 

Use 

(Replicates) 

MDAS.REPLICATES 

MDASJnteger 

Users  share  these  attributes  with  other  entities. 

MDAS_USER  attribute 

Type 

Use 

(Replicate  Group) 

Users  share  these  attributes  with  other  entities. 

MDAS.REPL.GRPN 

MDAS-REPL.GRPNC 

MDAS_string 

M  DAS -integer 

MDAS.REPL.GRPNV 

array 

MDAS_string 

MDAS-REPL.GRPI 

MDAS.REPL.GRPIC 

array 

MDAS-integer 

MDASJnteger 

MDAS.REPL.GRPIV 

array 

M  DAS  .string 

array 

MDAS-USER  attribute 

Type 

Use 

(Replicate  Domain) 

MDAS-REPL.DMNN 
M  D  AS_R  EP  L  _D  M  NN( 

MDAS-REPL_DMNN\ 

MDAS-REPL-DMNI 

MDAS-REPL.DMNIC 

MDAS_REPL_DMNIV 

M  DAS  .string 

J  MDAS-integer 
array 

r  MDAS_string 
array 

MDAS-integer 

MDAS-integer 

array 

MDAS_string 

array 

Users  share  these  attributes  with  other  entities. 

MDAS_USER  attribute 

Type 

Use 

(Repl.  Input  Lineage) 

MDAS-REPL-IN 

MDAS_REPL_INC 

MDAS-REPL.INV 

MDASJnteger 

MDAS-integer 

MDASJnteger 

array 

Users  share  these  attributes  with  other  entities. 

MDAS_USER  attribute 

Type 

Use 

(Repl.  Conseq.  Lineage) 

MDAS-REPL-OUT 

MDAS-REPL-OUTVC 

MDAS-REPL-OUTV 

MDASJnteger 

MDASJnteger 

MDASJnteger 

array 

Users  share  these  attributes  with  other  entities. 

MDAS-USER  attribute 

Type 

Use 

(Repl.  Gen.  Lineage) 

MDAS-REPL.GEN 

MDAS-REPL.GNP 

MDAS-REPL.GNR 

M  D  AS  -REPL  _GN  U 

MDASJnteger 

MDAS_string 

MDASJnteger 

MDASJnteger 

Users  share  these  attributes  with  other  entities. 
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MDAS-USER  attribute 

Type 

Use 

(Replication  Trigger) 

MDAS.REPL.TRGM 

MDAS.REPL.TRGP 

MDAS_REPL_TRGC 

MDAS.REPL_TRGM\ 

MDAS_REPL_TRGPV 

MDASJnteger 

MDASJnteger 

MDASJnteger 

MDASJnteger 

array 

MDASJnteger 
!  array 

Users  share  these  attributes  with  other  entities. 

MDAS-USER  attribute 

Type 

Use 

(Repl.  Re-Gen.  Policy) 

MDAS_REPL_PLCY 

MDASJnteger 

Users  share  these  attributes  with  other  entities. 

MDAS-USER  attribute 

Type 

Use 

(Replicate  Dates) 

MDAS-REPL-DATE 

MDAS-REPL-DATEV 

MDAS -time 
MDAS -time 
array 

Users  share  these  attributes  with  other  entities. 

MDAS_USER  attribute 

Type 

Use 

(Replicate  Permanence) 

M  DAS  _RE  P  L  _P  E  RM 
MDAS_REPL-PERM\ 

MDAS-REPL.PURG 

MDAS-REPL.PURGV 

MDAS_double 
MDAS -double 
array 

MDASJogical 

MDASJogical 

array 

Users  share  these  attributes  with  other  entities. 

MDAS_USER  attribute 

Type 

Use 

(Replicate  Format) 

MDAS-REPL.FMTH 

MDAS_REPL_FMTN 

MDAS_REPL_FMTN\ 

MDAS_REPL_FMTI 

MDAS-REPL.FMTIV 

MDASJogical 

MDAS_string 

MDAS_string 

array 

MDASJnteger 

MDASJnteger 

array 

Users  share  these  attributes  with  other  entities. 

MDAS-USER  attribute 

Type 

Use 

(Repl.  Storage  Resource  ) 

MDAS-REPL-RSCH 

MDAS-REPL.RSCN 

MDAS-REPL-RSCNV 

MDAS-REPL.RSCI 

MDAS_REPL_RSCIV 

MDASJogical 
MDAS -string 
MDAS_string 
array 

MDASJnteger 

MDASJnteger 

array 

Users  share  these  attributes  with  other  entities. 
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MDAS-USER  attribute 

Type 

Use  n 

(Repl.  Storage  Server  ) 

MDAS-REPL-SRVH 

M  D  AS-RE  P  L  _S  RVN 
MDAS.REPL.SRVNV 

MDAS_REPL_SRVI 

MDAS-REPL.SRVIV 

M  DAS -logical 

M  DAS  _st  ring 
MDAS_string 
array 

MDASinteger 

MDAS_integer 

array 

Users  share  these  attributes  with  other  entities. 

MDAS-USER  attribute 

Type 

Use 

(Repl.  Dir.  and  Name  ) 

MD  AS_RE  PL.DIRN 
MDAS_REPL_DIRNV 

MDAS-REPL-NAMN 

MDAS_REPL_NAMNA 

MDAS_string 

M  DAS  .string 
array 

MDAS-string 

7  MDAS_string 
array 

Users  share  these  attributes  with  other  entities. 

MDAS-USER  attribute 

Type 

Use 

(Replicate  Owner  ) 

M  D  AS.RE  P  L  -OWN 
MDAS-REPL-OWNV 

MDAS-string 

M  DAS  string 
array 

Users  share  these  attributes  with  other  entities. 

MDAS_USER  attribute 

Type 

Use  H 

(Replicate  SpecHist) 

MDAS-REPL.HSA 

M  DA  S.REPL-HST 
MDAS-REPL-HSS 
MDAS_REPL_HSC 
MDAS-REPL-HSAV 

MDAS.REPL-HSTV 

MDAS-REPL-HSSV 

MDAS_integer 
MDAS_t.ime 
MDAS_spectrur 
M  DAS  integer 
M  DAS -integer 
array 

MDAS-time 

array 

MDAS_spectrun 

array 

Users  share  these  attributes  with  other  entities. 

i 

i 

MDAS-USER  attribute 

Type 

Use 

(Replicate  Lock) 

MDAS-REPL-RLCK 

MDAS_REPL_RLCKS 

MDAS-REPL-RLCKE 

MDAS_REPL_RLCKD 

MDAS.REPL-WLCK 

MDAS_REPL_WLCKS 

MDAS-REPL-WLCKE 

MDAS-REPL-WLCKI 

MDASJogical 

MDAS_time 

MDAS_time 

M  DAS  integer 
MDASJogical 
MDAS_time 
!  MDAS_time 
)  MDASinteger 

Users  share  these  attributes  with  other  entities. 
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MDAS-USER  attribute 

Type 

Use 

(Replicate  Security) 

MDAS.REPL.AUTK 
MDAS.REPL.AUTM 
MDAS_REPL_RACCK 
MDAS_REPL_RACCA 
M  D  AS  _REP  L  AVACC  f 
M  D  AS  _R  E  P  L  _  WAC  C  A 
M  D  A  S  _RE  P  L  X  RYK 
MDAS.REPLXRYM 

MDAS.string 
MDASJnteger 
MDAS  .string 
’  MDAS_integer 
’  MDAS_string 

I  MDASJnteger 
MDAS^string 
MDASJnteger 

Users  share  these  attributes  with  other  entities. 

MDAS.USER  attribute 

Type 

Use 

(Replicate  Perf) 

MDAS_REPL_PERF 

TBD 

Users  share  these  attributes  with  other  entities. 

TBD. 

4. 7. 2 *3  Auxilary  Entities 
4. 7. 2*3.1  MDAS-FORMAT 

A  format  is  an  MDAS  token  that  identifies  the  digital  or  logical  structure  of  an  MDAS 
Entity. 

A  method  which  changes  the  format  of  an  MDAS  entity  without  changing  the  entity  content 
is  said  to  be  invariant. 

Format  metadata  have  a  few  attributes  common  to  data  sets  and  methods  but  no  storage. 

Here,  all  attributes  of  formats  are  listed  for  completeness.  Descriptions  are  only  given  for 
those  attributes  unique  to  formats. 

Unique  Format  Attributes 

TBD. 

Shared  Attributes 


MDAS _FOR MAT  attribute 

Type 

Use 

(Base) 

Formats  share  these  attributes  with  other  entities. 

MDAS.NAME 

MDAS_string 

MDASJD 

MDASJnteger 

MDAS-CDJD 

MDASJnteger 
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MDAS-FORMAT  attribute 

Type 

Use 

(Version) 

M  DAS  _VERS  ION 

MDAS-VERSIONX 

MDAS.VERSIONM 

MDAS.VERSIONP 

MDAS.VERSIONN 

MDAS_string 

MDASJogical 

M  DAS -integer 
MDASJnteger 
MDAS -integer 

Formats  share  these  attributes  with  other  entities. 

MDAS-FORMAT  attribute 

Type 

Use 

(Alias) 

MDAS-ALIAS 

MDAS-ALIASC 

MDAS.ALIASV 

MDAS  .string 
MDAS -integer 
MDAS_string 
array 

Formats  share  these  attributes  with  other  entities. 

MDAS_FORMAT  attribute 

Type 

Use 

(Documentation) 

MDAS -ABSTRACT 
MDAS.DOC 

MDAS -integer 
MDAS -integer 

Formats  share  these  attributes  with  other  entities. 

MDAS.FORMAT  attribute 

Type 

Use 

(Input  Lineage) 

MDAS.FMT.IN 

MDAS-FMT-INC 

MDAS-FMTJNV 

MDAS  .integer 
MDASJnteger 
MDAS -integer 
array 

Formats  share  these  attributes  with  other  entities. 

MDAS-FORMAT  attribute 

Type 

L^se 

(Consequential  Lineage) 

MDAS.FMT-OUT 

MDAS_FMT_OUTC 

M  D  AS_FMT_0  UTV 

MDASJnteger 

MDASJnteger 

MDASJnteger 

array 

Formats  share  these  attributes  with  other  entities. 

MDAS-FORMAT  attribute 

Type 

Use 

(Generation  Lineage) 

MDAS_FMT_GEN 

MDAS-FMT.GNP 

MDAS-FMT.GNR 

MDAS-FMT-GNU 

MDASJnteger 

MDAS_string 

MDASJnteger 

MDASJnteger 

Formats  share  these  attributes  with  other  entities. 

MDAS-FORMAT  attribute 

Type 

Use 

(Re-Generation  Policy) 

MDAS-FMT-PLCY 

MDASJnteger 

Formats  share  these  attributes  with  other  entities. 
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MDAS.FORMAT  attribute 

Type 

Use 

(Trigger) 

M  D  AS  _F  MT_T  RGM 
MDAS.FMT.TRGP 
MDAS_FMT_TRGC 
MDAS.FMT.TRGMV 

MDAS.FMT_TRGPV 

MDAS  Jnteger 
MDAS  -integer 
MDAS  Jnteger 
MDAS  Jnteger 
array 

MDAS  Jnteger 
array 

Formats  share  these  attributes  with  other  entities. 

MDAS.FORMAT  attribute 

Type 

Use 

(Instantiation  Date) 

MDAS.FMT.DATE 

MDAS  .time 

Formats  share  these  attributes  with  other  entities. 

MDAS.FORMAT  attribute 

Type 

Use 

(Instantiation  Permanence) 

MDAS-FMT-PERM 

MDAS-FMT.PURG 

MDAS -double 
MDAS  Jogical 

Formats  share  these  attributes  with  other  entities. 

MDAS.FORMAT  attribute 

Type 

Use 

(Catalog  SpecHist) 

MDAS_FMT_HSA 

M  D  AS_F  MT.HST 
MDAS-FMT-HSS 
MDAS-FMT.HSC 
MDAS_FMT_HSAV 

MDAS.FMT-HSTV 

MDAS_FMT-HSS  V 

MDAS -integer 
MDAS -time 
MDAS-spectrur 
MDAS  Jnteger 
MDAS  Jnteger 
array 

MDAS -time 

array 

MDAS-spectrur 

array 

Formats  share  these  attributes  with  other  entities. 

l 

CL 

MDAS.FORMAT  attribute 

Type 

Use 

(Catalog  Perf) 

MDAS-FMT.PERF 

TBD 

Formats  share  these  attributes  with  other  entities. 

TBD. 

4. 7.2. 3. 2  MD  AS  .SERVER 


A  server  is  an  MDAS.METHOD  specialized  for  access  to  specific  resources  or  storage  mediums. 
For  data  sets,  this  might  be  the  O/S  for  the  storage  resource  or  a  specialized  service  provider 
such  as  a  DBMS.  The  MDAS  library  is  compiled  with  drivers  for  MDAS  servers.  The 
library  matches  the  names  of  compiled  drivers  with  server  names  (or  id#Y)  at  run-time  to 
determine  access  requirements  for  services  requested  a  user. 

Unique  Method  Attributes 
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None.  A  server  is  a  method  with  MDAS_SERV_METH  set  to  true. 
Shared  Attributes 

An  MDAS.SERVER  has  all  the  attributes  of  an  MDAS^METHOD. 

4. 7.2.3. 3  MDASJPOLICY 


4. 7. 2.3.4  MDASACTION 


4. 7. 2*4  Collective  Entities 

4. 7.2*4. 1  MDAS-CD 

A  CD  is  an  MDAS  Catalog,  or  ’’Catalog  Data”.  Catalogs  are  a  data  set  with  a  specific  use 
in  MDAS. 

Open  question:  are  catalogs  replicated? 

Catalog  metadata  have  some  attributes  common  to  data  sets  and  methods,  but  are  not 
partitioned  into  segments.  Here,  all  attributes  of  catalogs  are  listed  for  completeness.  De¬ 
scriptions  are  only  given  for  those  attributes  unique  to  catalogs. 

Unique  Catalog  Attributes 

TBD. 

Shared  Attributes 

MDAS.CD  attribute  Type _ Use  _ 

(Base)  Catalogs  share  these  attributes  with  other  entities. 


MDAS  .NAME  MDAS_string 

MDAS-ID _  MDAS-integer 


(Version)  I  Catalogs  share  these  attributes  with  other  entities. 


MDAS-VERSION  MDAS^tring 

MDAS.VERSIONX  MDASJogical 
MDAS.VERSIONM  MDAS-integer 
MDAS.VERSIONP  MDASJnteger 
MDAS-VERSION  N  MDASJnteger 
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MDAS.CD  attribute 

Type 

Use 

(Alias) 

MDAS.ALIAS 

MDAS-ALIASC 

MDAS.ALIASV 

M  DAS  .string 
MDAS  -integer 
M  DAS  .string 
array 

Catalogs  share  these  attributes  with  other  entities. 

MDAS-CD  attribute 

Type 

Use 

(Documentation) 

MDAS-ABSTRACT 

MDAS.DOC 

MDASJnteger 

MDASJnteger 

Catalogs  share  these  attributes  with  other  entities. 

MDAS.CD  attribute 

Type 

Use 

(SD) 

MDAS_SD_TABLE 

MDAS-SD.KEYC 

MDAS-SD.COLS 

MDAS-SD-KEY-TYP ' 

MDAS.SD-KEYS 

MDAS_SD-LOB_COL 

MDASJnteger 

MDASJnteger 

MDAS_string 

array 

MDASJnteger 
MDAS_handle 
MDAS  .string 

Catalogs  share  these  attributes  with  other  entities. 

MDAS.CD  attribute 

Type 

Use 

(Logical  Group) 

MDAS-STOR.GRPN 

MDAS-STOR-GRPI 

MDAS-STOR-GRPNC 

MDAS-STOR-GRPNV 

MDAS_STOR_GRPIC 

MDAS-STOR-GRPIV 

MDAS -string 

MDASJnteger 

MDASJnteger 

MDAS_string 

array 

MDASJnteger 

MDASJnteger 

array 

Catalogs  share  these  attributes  with  other  entities. 

MDAS.CD  attribute 

Type 

Use 

(Logical  Domain) 

M  D  AS-STO  R_D  M  N  N 
MDAS-STOR-DMNI 
MDAS-STOR_DMNN< 
M  D  AS  -STO  R.D  M  N  N  > 

M  DAS  _ST  0  R_D  M  NIC 
M  D  AS-STO  R  _D  M  N I V 

MDAS-string 
MDASJnteger 
/  MDASJnteger 

1  MDAS-string 
array 

MDASJnteger 

MDASJnteger 

array 

Catalogs  share  these  attributes  with  other  entities. 

MDAS.CD  attribute 

Type 

Use 

(Input  Lineage) 

MDAS-STORJN 
MDAS.STOR-INC  ; 
MDAS-STOR.INV 

MDASJnteger 

MDASJnteger 

MDASJnteger 

array 

Catalogs  share  these  attributes  with  other  entities. 
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M  DAS -CD  attribute 

Type 

Use 

(Consequential  Lineage) 

MDAS_STOR_OUT 

MDAS.STOR.OUTC 

MDAS.STOR.OUTV 

MDASJnteger 

MDASinteger 

MDASJnteger 

array 

Catalogs  share  these  attributes  with  other  entities. 

MDAS-CD  attribute 

Type 

Use 

(Generation  Lineage) 

MDASJSTOR.GEN 

MDASJ5TOR.GNP 

MDASJSTOR-GNR 

M  D  A  S  J3TO  R_G  N  U 

M  DAS  .integer 
MDAS_string 
MDASJnteger 
MDASJnteger 

Catalogs  share  these  attributes  with  other  entities. 

MDAS_CD  attribute 

Type 

Use 

(Re- Generation  Policy) 

MDAS.STOR-PLCY 

MDASJnteger 

Catalogs  share  these  attributes  with  other  entities. 

MDAS-CD  attribute 

Type 

Use 

(Trigger) 

MDAS-STOR.TRGM 

MDAS-STOR-TRGP 

MDASJSTOR.TRGC 

MDAS_STOR_TRGM\ 

MDAS.STOR-TRGPV 

MDASJnteger 
MDASJnteger 
MDASJnteger 
'  MDASJnteger 
array 

MDASJnteger 

array 

Catalogs  share  these  attributes  with  other  entities. 

MDAS_CD  attribute 

Type 

Use 

(Storage  Date) 

MDAS.STOR.DATE 

MDAS-time 

Catalogs  share  these  attributes  with  other  entities. 

MDAS_CD  attribute 

Type 

Use 

(Storage  Permanence) 

MDAS-STOR-PERM 

MDAS-STOR.PURG 

MDAS.double 

MDASJogical 

Catalogs  share  these  attributes  with  other  entities. 

MDAS-CD  attribute 

Type 

Use 

(Storage  Format) 

MDAS_STOR_FMTN 
M  D  AS.STOR-F  MTI 

M  DAS  .string 
MDASJnteger 

Catalogs  share  these  attributes  with  other  entities. 

MDAS_CD  attribute 

Type 

Use 

(Storage  Resource) 

MDAS.STOR-RSCN 

MDAS-STOR-RSCI 

MDAS_string 

MDASJnteger 

Catalogs  share  these  attributes  with  other  entities. 
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MDAS-CD  attribute 

Type 

Use 

(Storage  Server) 

MDASJSTOR-SRVN 

MDAS.STOR.SRVI 

M  DAS  .string 

M  DAS  .integer 

Catalogs  share  these  attributes  with  other  entities. 

MDAS.CD  attribute 

Type 

Use 

(Storage  Path  and  Name) 

MDAS-STOR-DIR 

MDAS-STOR-NAM 

M  DAS  -string 
MDAS-string 

Catalogs  share  these  attributes  with  other  entities. 

MDAS-CD  attribute 

Type 

Use 

(Catalog  Owner) 

MDAS-STOR.OWN 

MDASJnteger 

Catalogs  share  these  attributes  with  other  entities. 

MDAS-CD  attribute 

Type 

Use 

(Catalog  SpecHist) 

MDAS-STOR-HSA 

MDAS.STOR-HST 

MDAS.STOR-HSS 

MDAS.STOR-HSC 

MDAS-STOR-HSAV 

MDAS_STOR-HSTV 

MDAS_STOR_HSSV 

MDASJnteger 

M  DAS -time 

MDAS^pectrur 

MDASJnteger 

MDASJnteger 

array 

MDAS.time 

array 

MDAS_spectrur 

array 

Catalogs  share  these  attributes  with  other  entities. 

1 

i 

MDAS_CD  attribute 

Type 

Use 

(Catalog  Perf) 

MDAS-STOR-PERF 

TBD 

Catalogs  share  these  attributes  with  other  entities. 

TBD. 

MDAS_CD  attribute 

Type 

Use 

(Catalog  Lock) 

MDAS-STOR.RLCK 

MDAS-STOR.RLCKS 

MDAS_STOR_RLCKE 

MDAS-STOR-RLCKD 

MDAS-STOR-WLCK 

MDAS-STOR-WLCKS 

MDAS-STOR_WLCKI 

MDAS_STOR_WLCKI 

MDASJogical 

M  DAS -time 

M  DAS -time 
MDASJnteger 
MDASJogical 
!  MDAS.time 
t  M DAS -time 
j  MDASJnteger 

Catalogs  share  these  attributes  with  other  entities. 
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MDAS-CD  attribute 

Type 

Use 

(Catalog  Security) 

MDAS-STOR-AUTK 
MDAS_STOR_AUTM 
MDAS_STOR_RACCE 
MDAS.STOR-RACC1V 
M  D  AS  _S  T  0  R_  WACC I 
MDAS.STOR-WACCJ 
MDAS-STOR-CRYK 
M  D  A  S  _S  TO  RX1  RYM 

MDAS_string 
MDASJnteger 
MDAS_string 
[  M  DAS  integer 
"  MDAS_string 

1  M  DAS  integer 
MDAS_string 
MDASJnteger 

Catalogs  share  these  attributes  with  other  entities. 

MDASXD  attribute 

Type 

Use 

(Replicates) 

MDAS.REPLICATES 

MDASJnteger 

Catalogs  share  these  attributes  with  other  entities. 

MDAS-CD  attribute 

Type 

Use 

(Replicate  Group) 

MDAS-REPL.GRPN 

MDAS-REPL.GRPNC 

MDAS-REPL.GRPNY 

MDAS-REPL-GRPI 

MDAS-REPL-GRPIC 

MDAS.REPL.GRPIV 

MDAS_string 

MDASJnteger 

array 

MDAS_string 

array 

MDASJnteger 

MDASJnteger 

array 

MDAS_string 

array 

Catalogs  share  these  attributes  with  other  entities. 

MDAS-CD  attribute 

Type 

Use 

(Replicate  Domain) 

MDAS-REPL-DMNN 

MDAS.REPL-DMNNC 

MDAS-REPL-DMNm 

MDAS-REPL.DMNI 

MDAS-REPL-DMNIC 

MDAS-REPL-DMNIV 

MDAS^tring 
)  MDASJnteger 
array 

r  M  DAS  .string 
array 

MDASJnteger 

MDASJnteger 

array 

MDAS_string 

array 

Catalogs  share  these  attributes  with  other  entities. 

MDAS_CD  attribute 

Type 

Use 

(Repl.  Input  Lineage) 

MDAS_REPLJN 

MDAS-REPL-INC 

MDAS.REPL.INV 

MDASJnteger 

MDASJnteger 

MDASJnteger 

array 

Catalogs  share  these  attributes  with  other  entities. 
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MDAS-CD  attribute 

Type 

Use 

(Repl.  Conseq.  Lineage) 

MDAS.REPL.OUT 
MDAS_REPL_OUTVC 
M  D  A  S  _R  E  P  L  _0  U  T  V 

MDASinteger 

MDASinteger 

MDASinteger 

array 

Catalogs  share  these  attributes  with  other  entities. 

MDAS-CD  attribute 

Type 

Use 

(Repl.  Gen.  Lineage) 

MDAS_REPL_GEN 

MDAS_REPL_GNP 

MDAS.REPL.GNR 

MDAS_REPL_GNU 

MDAS_integer 
M  DAS  .string 
MDASinteger 
MDASinteger 

Catalogs  share  these  attributes  with  other  entities. 

MDAS-CD  attribute 

Type 

Use 

(Replication  Trigger) 

MDAS-REPL.TRGM 
M  DAS  -RE  P  L  _T  RG  P 
MDAS_REPL_TRGC 
MDAS_REPL_TRGM\ 

MDAS-REPL.TRGPV 

MDASinteger 
MDASinteger 
MDASinteger 
r  MDASinteger 
array 

MDASinteger 

array 

Catalogs  share  these  attributes  with  other  entities. 

MDAS.CD  attribute 

Type 

Use 

(Repl.  Re-Gen.  Policy) 

MDAS_REPL_PLCY 

MDASinteger 

Catalogs  share  these  attributes  with  other  entities. 

MDAS-CD  attribute 

Type 

Use 

(Replicate  Dates) 

MDAS.REPL-DATE 

M  D  AS-R  E  P  L  -DAT  E  V 

MDAS-time 

M  DAS -time 
array 

Catalogs  share  these  attributes  with  other  entities. 

MDAS-CD  attribute 

Type 

Use 

(Replicate  Permanence) 

MDAS-REPL.PERM 

MDAS-REPL-PERMY 

MDAS-REPL.PURG 

MDAS-REPL-PURGV 

MDAS.double 

MDAS.double 

array 

MDASiogical 
;  MDASiogical 
array 

Catalogs  share  these  attributes  with  other  entities. 
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MDAS-CD  attribute 

Type 

Use 

(Replicate  Format) 

MDAS.REPL.FMTH 

MDAS.REPL-FMTN 

MDAS_REPL_FMTN\ 

MDAS.REPL-FMTI 

MDAS-REPL-FMTIV 

M  DAS -logical 
MDAS_string 
MDAS-string 
array 

M  DAS -integer 
MDASJnteger 
array 

Catalogs  share  these  attributes  with  other  entities. 

MDAS-CD  attribute 

Type 

Use 

(Repl.  Storage  Resource  ) 

MDAS-REPL-RSCH 

MDAS-REPL-RSCN 

MDAS-REPL-RSCNV 

MDAS-REPL.RSCI 

MDAS-REPL-RSCIV 

M  DAS -logical 
MDAS-string 
MDAS-string 
array 

M  DAS -integer 
M  DAS -integer 
array 

Catalogs  share  these  attributes  with  other  entities. 

MDAS-CD  attribute 

Type 

Use 

(Repl.  Storage  Server  ) 

MDAS-REPL-SRVH 
MDAS-REPL-SRVN 
MD  AS_REP  L_S  RVN  V 

MDAS_REPL_SRVI  I 
MDAS-REPL-SRVIV  ! 

MDASJogical 

MDAS_string 

M  DAS  jst  ring 
array 

MDASJnteger 

MDASJnteger 

array 

Catalogs  share  these  attributes  with  other  entities. 

MDAS_CD  attribute 

Type 

Use 

(Repl.  Dir.  and  Name  ) 

MDAS.REPL-DIRN 

MDAS-REPL.DIRNV 

MDAS-REPL.NAMN 

MDAS-REPL_NAMm 

MDAS_string 

MDAS_string 

array 

MDAS_st.ring 
r  MDAS_string 
array 

Catalogs  share  these  attributes  with  other  entities. 

MDAS_CD  attribute 

Type 

Use 

(Replicate  Owner  ) 

MDAS.RE  PL-OWN 
MDAS-REPL.OWNV 

MDAS-string 

MDAS_string 

array 

Catalogs  share  these  attributes  with  other  entities. 
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MDAS.CD  attribute 

Type 

Use 

(Replicate  SpecHist) 

MDAS.REPL.HSA 

MDAS.REPL.HST 

MDAS_REPL_HSS 

MDAS.REPL.HSC 

MDAS_REPL_HSAV 

MDAS_REPL_HSTV 

MDAS.REPL.HSSV 

MDASJnteger 

MDAS-time 

MDAS_spectruri 

MDASJnteger 

MDASJnteger 

array 

M  DAS  .time 
array 

MDAS_spectrur 

array 

Catalogs  share  these  attributes  with  other  entities. 

i 

i 

MDAS.CD  attribute 

Type 

Use 

(Replicate  Lock) 

MDAS-REPL.RLCK 

MDAS-REPL-RLCKS 

MDAS_REPL_RLCKE 

MDAS_REPL_RLCKD 

MDAS_REPL_WLCK 

MDAS.REPL.WLCKS 

MDAS-REPL-WLCKI 

M  DAS  _REP  L  _  W  L  CK I 

MDASJogical 

MDAS_time 

M  DAS -time 

MDASJnteger 

MDASJogical 

M  DAS  .time 

1  MDAS.time 
)  MDASJnteger 

Catalogs  share  these  attributes  with  other  entities. 

MDAS.CD  attribute 

Type 

Use 

(Replicate  Security) 

MDAS.REPL.AUTK 
MDAS-REPL.AUTM 
M  D  AS  _RE  P  L  _R  AC  C  Iv 
M  D  AS  _RE  P  L  _R  ACC  A 
MDAS_REPL_WACCh 
MDAS-REPL-WACCA 
MDAS-REPL.CRYK 
MDAS_REPL_CRYM 

MDAS-string 
MDASJnteger 
MDAS_string 
MDASJnteger 
’  MDAS-string 

I  MDASJnteger 
MDAS-string 
MDASJnteger 

Catalogs  share  these  attributes  with  other  entities. 

MDAS.CD  attribute 

Type 

Use 

(Replicate  Perf) 

MDAS.REPL-PERF 

TBD 

Catalogs  share  these  attributes  with  other  entities. 

TBD. 

4.7. 2. 4. 2  MDAS_DOMAIN 

Domains  are  functionally  equivalent  to  MDAS.GROUP,  but  have  the  additional  constraint  of 
access  control. 

Every  user  is  a  (singleton)  domain,  but  may  also  have  memberships  in  larger  domains. 
Domain  Attributes 
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MDAS-DOMAIN  attribute 

Type 

Use 

(Base) 

Domains  share  these  attributes  with  other  entities. 

MDAS.NAME 

M  DAS  .string 

MDAS.ID 

M  DAS  .integer 

MDAS.CDJD 

M  DAS -integer 

MDAS-DOMAIN  attribute 

Type 

Use 

(Version) 

MDAS.VERSION 

MDAS.VERSIONX 

MDAS.VERSIONM 

MDAS-VERSIONP 

MDAS-VERSIONN 

MDAS_string 

MDASJogical 

M  DAS -integer 
M  DAS -integer 
M  DAS -integer 

Domains  share  these  attributes  with  other  entities. 

MDAS-DOMAIN  attribute 

Type 

Use 

(Alias) 

MDAS.ALIAS 

MDAS-ALIASC 

MDAS.ALIASV 

MDAS_string 

M  DAS -integer 

MDAS_string 

array 

Domains  share  these  attributes  with  other  entities. 

MDAS-DOMAIN  attribute 

Type 

Use 

( Documentation ) 

M  D  A  S  -ABSTRACT 

M  DAS  _DOC 

MDAS_integer 
MDAS  -integer 

Domains  share  these  attributes  with  other  entities. 

MDAS-DOMAIN  attribute 

Type 

Use 

(Input  Lineage) 

MDAS-DMN-IN 

MDAS.DMNJNC 

MDAS-DMN-INV 

MDAS  integer 
MDAS  integer 
MDAS  integer 
array 

Domains  share  these  attributes  with  other  entities. 

MDAS-DOMAIN  attribute 

Type 

Use 

(Consequential  Lineage) 

MDAS-DMN-OUT 

MDAS_DMN_OUTC 

MDAS.DMN-OUTV 

MDAS  integer 
MDAS  integer 
MDASinteger 
array 

Domains  share  these  attributes  with  other  entities. 

MDAS-DOMAIN  attribute 

Type 

Use 

(Generation  Lineage) 

MDAS.DMN-GEN 

MDAS-DMN.GNP 

MDAS-DMN.GNR 

MDAS-DMN.GNU 

MDASinteger 

MDAS-string 

MDASinteger 

MDASinteger 

Domains  share  these  attributes  with  other  entities. 
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MDAS-DOMAIN  attribute 

Type 

Use 

(Re-Generation  Policy) 

MDAS.DMN-PLCY 

MDASJnteger 

Domains  share  these  attributes  with  other  entities. 

MDAS-DOMAIN  attribute 

Type 

Use 

(Trigger) 

MDAS-DMN.TRGM 

MDAS.DMN-TRGP 

MDAS.DMN-TRGC 

MDAS-DMN.TRGMV 

MDAS-DMN-TRGPV 

MDASJnteger 

MDASJnteger 

MDASJnteger 

MDASJnteger 

array 

MDASJnteger 

array 

Domains  share  these  attributes  with  other  entities. 

MDAS_DOMAIN  attribute 

Type 

Use 

(Storage  Date) 

MDAS-DMN.DATE 

M  DAS  .time 

Domains  share  these  attributes  with  other  entities. 

MDAS-DOMAIN  attribute 

Type 

Use 

(Storage  Permanence) 

MDAS-DMN.PERM 

MDAS-DMN-PURG 

M  DAS -double 
AIDAS  Jogical 

Domains  share  these  attributes  with  other  entities. 

MDAS-DOMAIN  attribute 

Type 

Use 

(Domain  Owner) 

MDAS_DMN_OWN 

MDASJnteger 

Domains  share  these  attributes  with  other  entities. 

MDAS-DOMAIN  attribute 

Type 

Use 

(Domain  SpecHist) 

MDAS_DMN_HSA 

MDAS-DAIN-HST 

MDAS-DMN-HSS 

MDAS-DMN.HSC 

MDAS-DMN-HSAV 

MDAS-DAIN-HSTV 

MDAS-DMN-HSSV 

MDASJnteger 

AIDAS -time 

AIDAS-spectrur 

AIDASJnteger 

AIDASJnteger 

array 

M  DAS -time 
array 

■  AIDAS-spectrur 
array 

Domains  share  these  attributes  with  other  entities. 

1 

i 

AIDAS.DOAIAIN  attribute 

Type 

Use 

(Domain  Perf) 

MDAS-DAIN-PERF 

TBD 

Domains  share  these  attributes  with  other  entities. 

TBD. 
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MDAS-DOMAIN  attribute 

Type 

Use 

(Domain  Security) 

M  D  AS  _D  M  N  _AU  T  I< 
MDAS_DMN_AUTM 
MDAS.DMN-RACCK 
MDAS.DMN.RACCM 

M  D  AS  _D  M  N  _WAC  C  K 
MDAS.DMN.WACCM 
MDAS.DMNJEACCK 

M  D  AS  _D  M  N_E  ACC  M 
MDAS.DMN.CRYK 

M  D  AS  _D  M  N_C  RYM 

MDAS  .string 

MDAS -integer 

MDAS_string 

MDASJnteger 

MDAS_string 

MDASJnteger 

MDAS_string 

MDASJnteger 

MDAS_string 

MDASJnteger 

Domains  share  these  attributes  with  other  entities. 

4.7.2.4.S  MD  AS  .GROUP 


A  group  is  a  set  of  MDAS  entities  with  a  common  attribute  encapsulated  in  the  group  name. 
Group  Attributes 


MDAS-GROUP  attribute 

Type 

Use 

(Base) 

Groups  share  these  attributes  with  other  entities. 

MDAS -NAME 

MDAS_st,ring 

MDASJD 

MDASJnteger 

MDAS.CDJD 

MDASJnteger 

MDAS-GROUP  attribute 

Type 

Use 

(Version) 

MDAS.VERSION 

MDAS.VERSIONX 

MDAS-VERSIONM 

MDAS.VERSIONP 

MDAS.VERSIONN 

MDAS-string 

MDASJogical 

MDASJnteger 

MDASJnteger 

MDASJnteger 

Groups  share  these  attributes  with  other  entities. 

MDAS-GROUP  attribute 

Type 

Use  o 

(Alias) 

Groups  share  these  attributes  with  other  entities. 

MDAS  _A  LIAS 

MDAS-string 

MDAS-ALIASC 

MDASJnteger 

M  DAS  _A  LI  AS  V 

MDAS-string 

array 

MDAS-GROUP  attribute 

Type 

Use 

(Documentation) 

MDAS- ABSTRACT 
MDAS -DOC 

MDASJnteger 

MDASJnteger 

Groups  share  these  attributes  with  other  entities. 
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MDAS.GROUP  attribute 

Type 

Use 

(Input  Lineage) 

MDAS.GRPJN 
MDAS.GRPJNC  j 

MDAS.GRPJNV 

M  DAS  integer 
MDASJnteger 
MDASinteger 
array 

Groups  share  these  attributes  with  other  entities. 

Ad  DAS -GROUP  attribute 

Type 

Use 

(Consequential  Lineage) 

MDAS-GRP-OUT 

MDAS_GRP_OUTC 

MDAS-GRP.OUTV 

MDASinteger 

MDASinteger 

MDASinteger 

array 

Groups  share  these  attributes  with  other  entities. 

MDAS.GROUP  attribute 

Type 

Use 

(Generation  Lineage) 

MDAS-GRP.GEN 

MDAS_GRP_GNP 

MDAS.GRP.GNR 

MDAS-GRP.GNU 

MDASinteger 
M  DAS  .string 
MDASinteger 
MDASinteger 

Groups  share  these  attributes  with  other  entities. 

MDAS.GROUP  attribute 

Type 

Use 

(Re-Generation  Policy) 

MDAS_GRP_PLCY 

MDASinteger 

Groups  share  these  attributes  with  other  entities. 

MDAS.GROUP  attribute 

Type 

Use 

(Trigger) 

MDAS.GRP.TRGM 
MDAS-GRP-TRGP 
MDAS-GRP.TRGC 
MDAS.GRP.TRGM  V 

MDAS_GRP-TRGP  V 

MDASinteger 

MDASinteger 

MDASinteger 

MDASinteger 

array 

MDASinteger 

array 

Groups  share  these  attributes  with  other  entities. 

MDAS.GROUP  attribute 

Type 

Use 

(Storage  Date) 

MDAS.GRP.DATE 

AID  AS  .time 

Groups  share  these  attributes  with  other  entities. 

MDAS.GROUP  attribute 

Type 

Use 

(Storage  Permanence) 

AIDAS-GRP.PERAI 

AIDAS.GRP.PURG 

AIDAS.double 

MDASiogical 

Groups  share  these  attributes  with  other  entities. 
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MDAS.GROUP  attribute 

Type 

Use 

(Domain  Owner) 

MDAS-GRP-OWN 

MDASJnteger 

Groups  share  these  attributes  with  other  entities. 

MDAS.GROUP  attribute 

Type 

Use 

(Domain  SpecHist) 

MDAS.GRP.HSA 

MDAS.GRP.HST 

MDAS.GRP-HSS 

MDAS.GRP.HSC 

M  DAS.G  RP.HS  AV 

MDAS.GRP.HSTV 

MDAS.GRP.HSSV 

MDASJnteger 

MDAS  .time 

MDAS_spectrur 

MDASJnteger 

MDASJnteger 

array 

MDAS.time 

array 

MDAS_spectrur 

array 

Groups  share  these  attributes  with  other  entities. 

i 

i 

MDAS.GROUP  attribute 

Type 

Use 

(Domain  Perf) 

MDAS.GRP.PERF 

TBD 

Groups  share  these  attributes  with  other  entities. 

TBD. 

4. 7. 2.4.4  MDAS_LIST 

An  entity  list  is  a  simple  list  of  entity  records.  It  typically  encountered  in  the  result  of 
MDAS.INQUIREC). 

An  MDAS_LIST  is  created  with 

MDAS_INFO_CREATE(  MDAS.LIST,  listinfo,  status  ) 
where  listinfo  is  an  infoh  structure  initialized  by  the  call. 

To  add  Info  structure  myinf o  to  a  list,  use 

MDAS_INFO_ADD_LATTR(  listinfo,  myinf o,  n,  status  ). 

The  list  element  number  n  assigned  to  the  entity  is  returned  by  the  call.  To  retrieve  the 
nth  Info  structure  from  a  list,  use 

MDAS_INFO_SCAN_LATTR(  listinfo,  $n$ ,  someinfo,  status  ) 
where  someinfo  is  an  infoh  structure  (re)initialized  by  the  call.  List  entities  can  be  deleted 
with 

MDAS_INFO_DEL_LATTR(  listinfo,  $n$,  status  ). 

The  number  of  entities  in  a  list  is  given  by  attribute  MDAS_LIST_COUNT  and  the  types  of  each 
entity  is  given  by  MDAS_LIST_TYPE.  These  attributes  may  be  scanned  with  MDAS_INFO_SCAN_ATTR() . 

To  create  “list  entities”  without  explicitly  declaring  individual  entity  handles,  use 
MDAS_INFO_CREATE_LEATTR(  entitytype,  listinfo,  $n$,  status  ) 
where  listinfo  is  the  name  of  an  existing  MDAS_LIST  Info  structure  and  entitytype  is 
a  valid  MDAS  entity.  The  list  element  number  n  assigned  to  the  entity  is  returned  by  the 
call. 


no 


To  set  attributes  of  “list  entities”  without  the  explicit  entity  handles,  use 
MDAS_INFCLSET_LEATTR(  attr,  value,  listinfo,  $n$,  status  ) 
where  attr  is  a  valid  attribute  for  the  entity  type  and  value  is  a  valid  value  for  the  attribute. 
To  read  values  directly  from  a  list  entity,  use 

MDAS_INFO_SCAN_LEATTR(  listinfo,  $n$,  attr,  value,  status  ) 

List  entity  replicate  (LER)  values  can  likewise  be  accessed  with 

MDAS_INFO_SET_LERATTR(  $r$,  attr,  value,  listinfo,  $n$,  status  ) 

and 

MDAS_INFO_SCAN_LERATTR(  listinfo,  $n$,  $r$,  attr,  value,  status  ) 
where  r  is  the  replicate  index  of  the  desired  attribute. 

List  Attributes 


MDAS-METHOD  attribute 

Type 

Use 

MDAS.LIST.COUNT 

MDAS -integer 

Number  of  entities  in  list. 

MDAS.LIST.TYPEV 

MDAS -integer 

Array  of  entity  types  corresponding  to  each  entity  in 

array 

the  list. 

MDAS -LIST  JNFOV 

MDAS -info  h 
array 

Array  of  Info  handles. 

4.7.2.4.5  MDASJ3ITE 


A  site  is  an  MDAS_RESOURCE  that  identifies  a  set  of  resources  known  to  users  as  a  “site”.  The 
MDAS_SITE  token  has  special  meaning  to  the  MDAS  Library,  but  is  otherwise  equivalant  to 
a  resource  entity.  Individual  resources  of  a  site  are  registered  as  segments  of  the  site  entity. 

Unique  Method  Attributes 


None.  x4  site  is  a  resource  with  MDAS_SITE_RSRC  set  to  true. 
Shared  Attributes 


An  MDAS.SITE  has  all  the  attributes  of  an  MDAS_RESOURCE. 


4. 7. 2. 5  Directive  Entities 

The  MDAS  Library  defines  several  entities  for  specifying  directives  in  Info  to  MDAS  Library 
routines  and  directive  flags  as  attributes  of  Catalog  metadata. 


4.7.2. 5.1  MDAS_DIRECTIVE 


MDAS_DIRECTIVE  is  functionally  equivalent  to  MDAS_LIST,  but  its  use  is  restricted  to  MDAS 
Library  calls  requiring  argument  lists  placed  in  an  Info  structure. 


Ill 


All  attributes  of  MDAS.DIRECTIVE  are  optional.  The  semantics  of  any  particular  attribute 
is  dependent  upon  its  use.  Most  members  are  designed  as  flags. 


MDAS-DIRECTIVE 
(zero  or  more  of:) 
MDASJNPUT 
MDAS.OUTPUT 
MDAS.READ 
M  DAS  .WRITE 
MDAS.READWRITE 
MDAS.APPEND 
M  DAS -SPOOL 


4. 7. 2. 6  Conditional  Entities 

Conditional  entities  are  used  wherever  an  Info  structure  must  specify  logical  semantics 
to  an  MDAS  Library  function.  A  primary  use  is  the  cond  argument  to  MDAS_INQUIRE() 
(section  4. 7.3. 2.1). 

For  example,  suppose  a  user  is  interested  in  finding  Catalog  id#’s  for  any  entity  whose 
name  equals  "kilroy".  To  specify  this  query  to  MDAS_INQUIRE().  a  user  program  would 
place  the  following  attribute  in  the  info  argument 

MDAS.ENTITY  MDAS-ANY  (null) 


and  these  two  attributes  in  the  cond  argument: 

MDAS.CRITERIA  MDAS.NAME  ‘kilroy” 

MDASTIMIT  MDAS-ANY  MDAS JD 


Upon  successful  return  from  MDAS_INQUIRE() ,  the  calling  program  would  receive  a  list  in 
the  result  parameter  containing  Catalog  id#’s  for  entities  matching  the  query: 


MDAS-LIST 

MDAS.LIST.COUNT  n 


More  information  on  Conditional  Entities  is  given  in  the  following  subsections. 


4. 7.2.6. 1  MDAS_ANY 

MDAS_ANY  is  a  wild-card  token  which  is  used  in  the  context  of  queries. 
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4.7. 2. 6. 2  MDAS -CONDITION 


MDAS^CONDITION  is  used  to  specify  logical  conditions  to  MDAS  Library  functions.  These 
conditions  may  be  listed  sequentially,  or  built  in  tree-like  hierarchies  to  specify  complex 
logic  requirements.  Like  most  conditional  entities,  all  attributes  of  MDAS^CONDITION  are 
optional. 

MDAS.CONDITION 
MDASJEQUIV 
MDAS-NOT 
MDAS  _AND 
MDAS-OR 
MDAS.NAND 
MDAS.NOR 
MDAS.ANY 


4.7.2. 6.3  MDAS_CRITERIA 


MDAS-CRITERIA 
MDAS-TOKEN 
MDAS-SUBSTR 
M  DAS-LIKE 
MDAS.ORIGIN 
MDAS.BEST 
MDAS -DISTINCT 
MDAS.ANY 


4. 7. 2. 6.4  MDAS_LIMIT 


MDAS.LIMIT 

(any  valid  entity) 

(any  attribute  of  the  entity) 
MDAS.ANY 


4. 7.2. 6. 5  MDAS_EXTENT 


MDAS.EXTENT 
MDAS-LOCAL 
MDAS-WIDE 
M  D  AS_U  N I  VERS  E 
MDAS  _A  NY 
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4.7.3  API  Prototypes 


The  following  descriptions  of  MDAS  function  prototypes  are  provided  as  a  reference  to  the 
MDAS  High-Level  API.  Example  use  of  each  function  is  given  in  procedural  pseudo-code. 
For  a  tutorial  style  introduction,  please  see  the  MDAS  User  Guide  and  Tutorial. 


4. 7. 3.1  Library  Initialization  and  Cleanup 

The  MDAS  Library  requires  initialization  of  internal  parameters  and  run-time  resources 
before  use.  Likewise,  a  clean-up  process  is  required  when  the  application  program  no 
longer  needs  MDAS  library  resources.  The  routines  MDAS_INIT()  and  MDAS_FINALIZE() 
are  provided  for  this  purpose. 

4.7.3. 1.0.1  MDASJNITO 

MDAS_INIT(argc,  argv,  comm,  status) 

argv:  (IN)  array  of  character  string 

argc:  (IN)  integer 

comm:  (IN)  handle 

status:  (IN/OUT)  MDAS_status 


status  codes 

type 

meaning 

MDAS.SUCCESS 

MDAS.WARN.MDASRC 

MDAS_WARN_TICKETS 

MDAS_WARN_MPI 

MDAS_ERR_MEMORY 

success 

warning 

warning 

warning 

error 

MDAS  library  initialized 
no  run-time  mdasrc  data  found 
no  run-time  ticket  data  found 
comm  non-NULL  but  no  MPI 
unable  to  allocate  memory 

MDAS.INITO  allocates  memory  for  basic  library  operations  and  initializes  library  run-time 
parameters  as  described  in  section  4.5.  The  arguments  argv  and  argc  are  the  standard 
string  and  count  structures  for  command  line  argument  lists  encountered  in  Unix  and  other 
operating  systems.  The  comm  argument  is  used  only  when  the  application  is  linked  to  an 
MPI-enabled  version  of  MDAS;  it  is  otherwise  ignored. 


4.7.3. 1.0. 2  MDAS_FINALIZE() 

MDAS_FINALIZE(comm, status) 

comm:  (IN)  handle 

status:  (IN/OUT)  MDAS_status 
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status  codes 

type 

meaning 

MDAS.SUCCESS 

success 

MDAS  library  finalized 

MDAS_WARN_COMM 

warning 

comm  different  from  MDAS_INIT 

MDAS_WARN_MPI 

warning 

comm  non-NULL  but  no  MPI 

MDAS_ERR_INIT 

error 

MDAS  not  initialized 

MDAS_ERR_MEMORY 

error 

unable  to  free  all  allocations 

MDAS_ERR_CONNECT 

error 

unable  to  close  all  connections 

MDAS_ERR_COMM 

error 

comm  not  part  of  MDAS^INIT  comm 

MDAS_FINALIZE()  resets  library  parameters,  closes  any  open  connections,  and  frees  any 
memory  allocated  by  MDAS  library  calls. 


4.7.3.1.0.3  MDAS_INIT()  and  MDAS_FINALIZE()  Examples 

The  following  example  assumes  that  argv  and  argc  are  system-defined  variables. 

PROGRAM  dolittle 

MDAS.status  status 

MDAS_INIT(argc ,  argv,  NULL,  status) 

MDAS_FINALIZE(NULL, status) 

END  PROGRAM 

The  following  example  assumes  that  argv  and  argc  are  system-defined  variables.  The 
handle  MPI_C0MM_W0RLD  is  defined  by  MPI. 

PROGRAM  do_mpi 

integer  ierr 
MDAS_status  status 

MPI_INIT(ierr) 

MDAS_INIT(argc,  argv,  MPI_C0MM_W0RLD ,  status) 

MDAS.FINALIZE (MPI_C0MM_W0RLD , status) 

MPI_FINALIZE(ierr) 

END  PROGRAM 
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4. 7. 3. 2  Info  Operations  on  MDAS  Catalogs 


4. 7. 3. 2.1  Obtaining  Info  From  MDAS  Catalogs 

MDAS.INFO.INQUIREQ  operates  on  catalogs  of  MDAS  metadata  stored  in  external  metadata 
servers.  The  existence  and  location  of  such  servers  are  identified  either  at  (a)  MDAS 
installation  time  and/or  (b)  application  run-time.  See  sections  4.5  and  4.13  for  details. 


4.7.3.2.1.1  MDAS  _INF0 -INQUIRE  () 


MDAS_INFO_INQUIRE(inf o ,  cond,  extent,  result,  status) 


info:  (IN) 

cond:  (IN) 

extent:  (IN) 
result:  (OUT) 
status:  (IN/OUT) 


MDAS.INFOH 

MDAS_INFOH 

MDAS.INFOH 

MDAS.INFOH 

MDAS.status 


status  codes 

type 

meaning 

MDAS.SUCCESS 

success 

result (s)  obtained 

MDAS_WARN_INFG 

warning 

info  is  empty  or  NULL 

MDAS.WARN.COND 

warning 

cond  is  empty  or  NULL 

MDAS.WARN.EXTENT 

warning 

extent  is  empty  or  NULL 

MDAS.WARN.RESULT 

warning 

result  is  empty 

MDAS.ERR.INIT 

error 

MDAS  not  initialized 

MDAS.ERR.INFO 

error 

invalid  info 

MDAS.ERR.COND 

error 

invalid  cond 

MDAS.ERR.EXTENT 

error 

invalid  extent 

MDAS.ERR. RESULT 

error 

invalid  result 

MDAS.ERR.MEMORY 

error 

unable  to  allocate  memory 

The  info  argument  should  specify  known  static  information  about  the  desired  item,  however 
sparse  or  incomplete.  For  example,  a  user  may  wish  to  specify  the  MDAS.TYPE  and  a  portion 
of  the  name  or  descriptive  keywords  in  info. 

The  cond  argument  is  used  to  specify  conditions  and  criteria  binding  on  the  query.  The 
tokens  MDAS.CONDITION  and  MDAS.CRITERIA  are  provided  for  this  purpose.  (See  section 
4. 7. 2. 6.) 

The  extent  of  catalogs  searched  are  specified  in  extent.  MDAS.EXTENT  may  be  used  in  com¬ 
bination  with  MDAS.CONDITION  and  extent  to  fully  qualify  the  catalog  search  boundaries. 
If  NULL  is  given  by  the  user,  default  catalogs  specified  by  the  run-time  environment  are 
searched. 

Query  results  are  returned  in  result  (which  may  be  internally  spooled).  If  no  matches 
are  found,  result  is  returned  empty  and  an  error  is  returned  in  status.  Users  are  re- 
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sponsible  for  freeing  the  memory  allocated  for  result  with  either  MDAS.INFO.FREEQ  or 
MDAS.FIHALIZEO. 

4.7.3. 2. 1.2  MDAS .INFO .INQUIRE!)  Example 

4. 7. 3. 2. 2  Catalog  Info  Registration 

MDAS_  INFO  .REGISTER!)  operates  on  catalogs  of  MDAS  metadata  stored  in  external  meta¬ 
data  servers.  The  existence  and  location  of  such  servers  are  identified  either  at  MDAS 
installation  time  (section  4.13)  and/or  application  run-time  (section  4.5). 

To  register  Info  about  users,  data  sets,  methods,  or  resources  to  an  MDAS  Catalog,  a 
minimal  set  of  attributes  is  required.  These  may  be  specified  by  the  user,  and  in  some  cases 
are  automatically  generated  by  the  MDAS  Library. 


4.7.3. 2. 2.1  MDAS_INF0  .REGISTER!) 


MDAS_INFO_REGISTER!info,  extent,  status) 
info:  (IN/OUT)  MDAS.INFOH 

extent:  !IN)  MDAS.INFOH 

status:  !IN/0UT)  MDAS.status 


status  codes 

type 

meaning 

MDAS_SUCCESS 

success 

info  registered 

MDAS_WARN„INFO 

warning 

info  is  empty 

MDAS.WARN.EXTENT 

warning 

extent  is  empty  or  NULL 

MDAS.WARN.REGISTER 

warning 

info  previously  registered 

MDAS.ERR.INIT 

error 

MDAS  not  initialized 

MDAS.ERR.INFO 

error 

invalid  info 

MDAS.ERR.EXTENT 

error 

invalid  extent 

MDAS.ERR.MEMORY 

error 

unable  to  allocate  memory 

MDAS.ERR.REGISTER 

error 

insufficient  metadata 

MDAS.INFO.REGISTER!)  adds  information  about  users,  data  sets,  methods,  and  resources 
to  one  or  more  catalogs.  Specifying  NULL  in  extent  will  select  the  default  catalog.  If  info 
does  not  contain  the  minimal  metadata  required  for  registration  in  an  MDAS  Catalog,  an 
error  is  returned  in  status  and  attributes  (with  empty  values)  of  the  required  attributes 
are  appended  to  info. 


4.7.3. 2. 2. 2  MDASJNFO .REGISTER!)  Example 


PROGRAM  reginfo 
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MDAS_status  status 
MDAS.INFOH  myinfo 

MDAS_INIT(argc ,  argv,  NULL,  status) 

MDAS_INFO_CREATE(MDAS_METHOD,  myinfo,  status) 
MDAS_INFO_SET_ATTR(MDAS_NAME ,  "myfilter",  myinfo,  status) 
MDAS_INFO_SET_ATTR(MDAS_STOR_RSCN,  "moon.com",  myinfo,  status) 
MDAS_INFO_SET_ATTR(MDAS_STOR_DIR,  "/users/kilroy/bin/" ,  myinfo,  status) 

MDAS_INFO_REGISTER(myinf o ,  NULL,  status) 

MDAS.FINALIZECNULL, status) 

END  PROGRAM 


4. 7. 3. 3  Returning  Status  Messages 

The  MDAS  Library  provides  3  procedures  to  generate  status  messages  from  status  codes. 
All  of  these  procedures  take  status  vectors  as  input.  The  contents  of  status  is  not  altered. 


4.7.3.3.0.3  MDAS_STATUS_PRINT  ( ) 

MDAS_STATUS_PRINT(status) 

status:  (IN)  MDAS_status 


MDAS_STATUS_PRINT  is  one  of  a  very  few  routines  that  are  guaranteed  to  work  outside  of 
MDAS_INIT()  and  MDAS_FINALIZE() .  It  interprets  the  contents  of  status  and  prints  the 
corresponding  status  message(s)  to  the  0/S  equivalent  of  standard  output,  one  line  per 
message.  MDAS.STATUS.PRINT  ignores  status(O)  and  status(l). 


4. 7. 3.3. 0.4  MDAS  .STATUS  _MSG  () 


MDAS_STATUS_MSG(code ,  procid,  msg) 
code:  (IN)  integer 

procid:  (IN)  integer 

msg:  (OUT)  MDAS_string 


MDAS_STATUS_MSGis  also  guaranteed  to  work  outside  of  MDAS_INIT()  and  MDAS_FINALIZE() . 
The  code  argument  should  contain  one  MDAS  status  bit  code  corresponding  to  MDAS  Li¬ 
brary  procedure  id^  procid.  If  code  and  procid  are  valid,  then  up  to  31  characters  of 
string  data  are  returned  in  msg.  Otherwise,  msg  is  empty  on  return. 
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4.7. 3.3.0. 5  MDAS_STATUS_INFO() 


MDAS.STATUS.INFO (status,  info) 

status:  (IN)  MDAS.status 

info:  (OUT)  MDAS.INFOH 

MDAS_STATUS_INFO  requires  that  the  MDAS  Library  be  initialized.  It  creates  an  Info 
structure  in  info  from  the  contents  of  status.  No  structure  is  created  if  status  is  invalid. 
MDAS_STATUS_INFO  ignores  status (0)  and  status (1). 

4.7.3.3.0.6  Example  use  of  MDAS.STATUS-PRINT ( )  and  MDAS_STATUS_MSG() 

In  the  following  examples,  program  checkstat  examines  status,  prints  any  error  or  warning 
messages,  then  exits  on  error.  Program  printstat  prints  the  entire  table  of  MDAS  status 
codes.  Program  checkrc  checks  to  see  if  MDAS_INIT()  found  resource  information  in  the 
local  environment.  If  not,  the  status  message  associated  with  this  condition  is  printed  and 
the  program  exits. 

PROGRAM  checkstat 

MDAS_status  status 

MDAS_INIT(argc,  argv,  NULL,  status) 
if  (status(O)  .ne.  0) 

MDAS_STATUS_PRINT (status) 
if  (status (0)  <  0)  exit 
end  if 

MDAS_FINALIZE(NULL, status) 

END  PROGRAM 


PROGRAM  printstat 

MDAS_status  status 
integer  p 

status (2)  =  FFFFFFFF 
for  status(3)  =  1,  MDAS_PR0C_C0UNT 
MDAS_STATUS_PRINT (status ) 
end  for 

END  PROGRAM 


PROGRAM  checkrc 
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MDAS.status  status 
character  msg(32) 

MDAS_INIT(argc,  argv,  NULL,  status) 
if  (status (2)  &  MDAS_WARN_MDASRC) 

MDAS_STATUS_MSG(MDAS_WARN_MDASRC,  status (3),  msg) 
MDAS_FINALIZE(NULL, status) 
print  msg 
exit 
end  if 

MDAS_FINALIZE(NULL, status) 

END  PROGRAM 


4. 7. 3.4  Info  Management 

4. 7. 3.4.1  Creating  Your  Own  Info 

MDAS  Info  structures  can  be  created  by  either  initializing  a  new  MDAS_INFOH  with 
MDAS. INFO .CREATE ()  or  copying  an  existing  Info  structure  into  a  new  area  of  memory 
with  MDAS.INFO.DUP ( ) .  Existing  Info  structures  can  be  purged  from  program  memory 
with  MDAS.INFO. FREE ( ) . 


4.7. 3. 4. 1.1  MDAS_INFO_CREATE() 


MDAS. INFO_CREATE( entity,  info,  status) 
entity:  (IN)  MDAS.token 

info:  (OUT)  MDAS.INFOH 

status:  (IN/OUT)  MDAS.status 


status  codes 

type 

meaning 

MDAS.SUCCESS 

success 

info  created 

MDAS.ERR.INIT 

error 

MDAS  not  initialized 

MDAS.ERR.INFO 

error 

invalid  info 

MDAS.ERR.MEMORY 

error 

unable  to  allocate  memory 

MDAS.ERR.TOKEN 

error 

invalid  MDAS.token 

MDAS.INFO  .CREATE  ( )  allocates  memory  for  an  MDAS.info  structure  for  the  entity  spec¬ 
ified  by  entity.  No  calls  are  made  to  MDAS  Catalogs.  To  place  values  in  the  struc¬ 
ture,  use  MDAS.INFO.SET.ATTRO,  MDAS_INFO_SET_RATTR()  (for  attributes  of  replicates). 
MDAS.INFO.ADD.LATTRO  (for  attributes  of  lists).  MD AS _ INF 0 .SET.LE ATTR ( )  (for  list  enti¬ 
ties),  and  MDAS. INF 0 .SET.LERATTR ( )  (for  list  entity  replicates). 
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4. 7. 3.4. 1.2  MDAS_INFO_DUP  ( ) 

MDAS_INFO_DUP(oldinfo,  newinfo,  status) 
infol:  (IN)  MDAS.INFOH 

info2 :  (OUT)  MDAS.INFOH 


status  codes 

type 

meaning 

MDAS.SUCCESS 

MDAS.WARN.INFO 

MDAS.ERR.INIT 

MDAS.ERR.MEMORY 

success 

warning 

error 

error 

info2  created  from  infol 
infol  is  empty 

MDAS  not  initialized 
unable  to  allocate  memory 

MDAS_INFO_DUP()  allocates  memory  for  the  contents  of  info2  and  then  initializes  it  with 
the  contents  of  infol. 


4. 7. 3.4. 1.3  MDAS_INFO_FREE() 

MDAS_INFO_FREE(info,  status) 

info:  (IN/OUT)  MDAS.INFOH 

status:  (IN/OUT)  MDAS_status 


status  codes 

type 

meaning 

MDAS.SUCCESS 

success 

info  deallocated 

MDAS.WARN.INFO 

warning 

info  is  empty 

MDAS.ERR.INIT 

error 

MDAS  not  initialized 

MDAS.ERR.INFO 

error 

invalid  info 

MDAS.ERR.MEMORY 

error 

unable  to  free  all  allocations 

MDAS_INFO_FREE()  deallocates  all  memory  associated  with  info.  Upon  return,  the  value 
of  info  is  NULL.  Any  Info  structures  not  explicitly  freed  with  MDAS_INFO_FREE()  will  be 
purged  during  MDAS_FINALIZE(). 

4.7.3.4.1.4  Example  use  of  MDAS_INFO_CREATE()  and  MDAS _INF0_FREE() 


PROGRAM  createinfo 

MDAS_status  status 
MDAS.INFOH  dsinfo 

MDAS_INIT(argc,  argv,  NULL,  status) 

MDAS. INFO .CREATE (MDAS.DATASET,  dsinfo,  status) 


121 


MDAS_INFO_FREE(dsinfo ,  status) 
MDAS_FINALIZE(NULL , status) 

END  PROGRAM 

4. 7. 3.4. 1.5  MDAS_INFO_DUP()  Example 

PROGRAM  dupinfo 

MDAS_status  status 
MDAS.INFOH  dsinfol,  dsinfo2 

MDAS_INIT(argc,  argv,  NULL,  status) 

MDAS_INFO_CREATE(MDAS_DATASET,  dsinfol,  status) 

MDAS_INFO_DUP(dsinfol ,  dsinfo2,  status) 

MDAS_FINALIZE(NULL, status) 

END  PROGRAM 

4. 7. 3.4. 2  Setting  Info  Attributes 


4.7. 3.4.2. 1  MDAS_INFO_SET_ATTR() 

MDAS_INFO_SET_ATTR()  sets  a.  metadata  attribute  in  an  existing  MDAS.info  structure. 

MDAS_INFO_SET_ATTR(attr ,  value,  info,  status) 
attr:  (IN)  MDAS_token 

value:  (IN)  pointer  (choice) 

info:  (IN/OUT)  MDAS.INFOH 

status:  (IN/OUT)  MDAS.status 


status  codes 

type 

meaning 

MDAS.SUCCESS 

success 

added  1  attribute  to  info 

MDAS.WARN.NULL 

warning 

added  NULL  attribute 

MDAS.WARN.TOKEN 

warning 

NULL  MDAS.token 

MDAS.WARN.VALUE 

warning 

NULL  value 

MDAS.ERR.INIT 

error 

MDAS  not  initialized 

MDAS.ERR.MEMORY 

error 

unable  to  allocate  memory 

MDAS.ERR.TOKEN 

error 

invalid  MDAS.token 

MDAS.ERR.DATATYPE 

error 

invalid  MDAS.datatype  for  value 

MDAS.ERR.INFO 

error 

invalid  info 
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4. 7. 3.4. 2. 2  MDAS_INFQ_SET_ATTR()  Example 


PROGRAM  addinfo 

MDAS.status  status 
MDAS.INFOH  dsinfo 

MDAS_INIT(argc,  argv,  NULL,  status) 

MDAS_INFO_CREATE(MDAS_DATASET,  dsinfo,  status) 
MDAS_INFO_SET_ATTR(MDAS_NAME,  "fin.dat",  dsinfo,  status) 
MDAS_INFO_SET_ATTR(MDAS_NAME,  "netcdf",  dsinfo,  status) 

MDAS_FINALIZE(NULL, status) 

END  PROGRAM 


4. 7.3.4. 3  Scanning  Info  Attributes 


4.7.3.4.3.1  MDAS_INFO_SCAN_ATTR() 

MDAS_INFO_SCAN_ATTR(inf o ,  attr,  value,  status) 
info:  (IN)  MDAS.INFOH 

attr:  (OUT)  MDAS_token 

value:  (OUT)  pointer  (choice) 

status:  (IN/OUT)  MDAS_status 


status  codes 

type 

meaning 

MDAS.SUCCESS 

MDAS_WARN_ATTR 

MDAS.ERR.INIT 

MDAS_ERR_INFO 

MDAS_ERR_ATTR 

success 

warning 

error 

error 

error 

item(s)  scanned 
attribute  value  is  NULL 
MDAS  not  initialized 
invalid  info 

invalid  attribute  for  entity 

MDAS_INFO_SCAN_ATTR()  returns  the  attr  attribute  value  for  a  given  Info  entity.  A  warn¬ 
ing  is  returned  in  status  if  info  has  no  attributes. 


4. 7. 3.4. 4  MDASAIST  Entities  and  Attributes 

An  entity  list  is  a  simple  list  of  entity  records.  It  typically  encountered  in  the  result  of 
MDAS.INQUIREO. 

An  MDAS.LIST  is  created  with 

MDAS_INFO_CREATE (MDAS.LIST ,  ilist,  status) 
where  ilist  is  an  infoh  structure  initialized  by  the  call. 
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The  number  of  entities  in  a  list  is  given  by  attribute  MDAS.LIST.COUNT  and  the  types  of  each 
entity  is  given  bv  MDAS_LIST_TYPE.  These  attributes  may  be  scanned  with  MDAS.INFO.SCAN.ATTRQ. 


4.7.3.4.4.1  MDAS_INFO_ADD_LATTR() 


MDAS_INFO_ADD_LATTR(ilist ,  myinfo,  n,  status) 
ilist:  (IN/OUT)  MDAS.INFOH 

myinfo:  (IN/OUT)  MDAS.INFOH 
n:  (OUT)  MDAS_integer 

status:  (IN/OUT)  MDAS_status 


Use  MDAS.INFO.ADD.LATTR  to  add  myinfo  to  list  ilist.  The  list  element  number  n  assigned 
to  the  entity  is  returned  by  the  call. 


4.7.3.4.4.2  MDAS_INFO_SCAN_LATTR() 


To  retrieve  the  rath  Info  structure  from  a  list,  use 


MDAS_INFO_SCAN_LATTR(ilist ,  n,  myinfo,  status) 
ilist:  (IN/OUT)  MDAS.INFOH 
n:  (IN)  MDAS.integer 

myinfo:  (IN/OUT)  MDAS.INFOH 
status:  (IN/OUT)  MDAS.status 


where  someinfo  is  an  inf  oh  structure  ( reinitialized  by  the  call. 


4. 7. 3.4. 4. 3  MDAS_INFO_DEL_LATTR() 

MDAS_INFO_DEL_LATTR(ilist ,  n,  status) 
ilist:  (IN/OUT)  MDAS.INFOH 

n:  (IN)  MDAS.integer 

status:  (IN/OUT)  MDAS.status 

MDAS.INFO.DEL. L ATTR ( )  deletes  list  entities. 


4. 7. 3.4. 4. 4  MDASJNFO  .CREATE  J.EATTR  ( ) 


MDAS_INFO_CREATE_LEATTR(type ,  ilist,  n,  status) 
type:  (IN)  MDAS.token 

ilist:  (IN/OUT)  MDAS.INFOH 

n:  (OUT)  MDAS.integer 

status:  (IN/OUT)  MDAS.status 
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To  create  “list  entities”  without  explicitly  declaring  individual  entity  handles,  use  MDAS_INFO_CREATE 
where  ilist  is  the  name  of  an  existing  MDAS_LIST  Info  structure  and  type  is  a  valid  MDAS 
entity  type.  The  list  element  number  n  assigned  to  the  entity  is  returned  by  the  call. 


4. 7. 3.4. 4. 5  MDAS_INF0J3ET_LEATTR() 

MDAS_INFO_SET_LEATTR(attr ,  value,  ilist,  n,  status) 
attr:  (IN)  MDAS.token 

value:  (IN)  pointer  (choice) 

ilist:  (IN/OUT)  MDAS.INFOH 

n:  (IN)  MDAS_ integer 

status:  (IN/OUT)  MDAS_status 


Use  MDAS_INFO_SET_LEATTR()  to  set  attributes  of  “list  entities”  without  the  explicit  entity 
handles.  The  token  attr  must  be  a  valid  attribute  for  the  entity  type  and  value  must  be 
a  valid  value  for  the  attribute. 


MDAS_INFO_SCAN_LEATTR(ilist ,  n,  attr,  value,  status) 
ilist:  (IN/OUT)  MDAS_INFOH 

n:  (IN)  MDAS_integer 

attr:  (IN)  MDAS_token 

value:  (IN)  pointer  (choice) 

status:  (IN/OUT)  MDAS_status 


4. 7. 3.4.4. 7  MDAS_INFO_SET_LERATTR() 

MDAS_INFO_SET_LERATTR(r ,  attr,  value,  ilist,  n,  status) 
r:  (IN)  MDAS_ integer 

attr:  (IN)  MDAS.token 

value:  (IN)  pointer  (choice) 

ilist:  (IN/OUT)  MDAS.INFOH 

n:  (IN)  MDAS_integer 

status:  (IN/OUT)  MDAS.status 

List  entity  replicate  (LER)  values  can  be  accessed  with  MDAS_INFO_SET_LERATTR()  where 
r  is  the  replicate  index  of  the  desired  attribute. 


4. 7. 3. 4. 4. 8  MDAS_INFO-SCAN_LERATTR( ) 


MDAS_INFO_SCAN_LERATTR(ilist ,  n,  r,  attr,  value. 


ilist:  (IN/OUT) 

n:  (IN) 

r:  (IN) 

attr:  (IN) 

value:  (IN) 

status:  (IN/OUT) 


MDAS_INFOH 
MDAS_ integer 
MDAS_ integer 
MDAS.token 
pointer  (choice) 
MDAS_status 


status) 


4. 7. 3.4. 5  Selecting  Info 

Queries  on  MDAS  Catalogs  by  MDAS_INQUIRE()  will  often  return  metadata  on  multiple 
items  in  result.  The  user  can  of  course  manually  transverse  the  MDAS.LIST,  then  (based 
on  some  user-defined  decision  mechanism)  copy  a  particular  item  to  a  new  Info  structure 
for  further  use.  Another  alternative  is  to  rely  on  default  selection  criteria  when  supplying 
several  items  in  a  single  Info  structure  to  a  procedure  that  must  use  exactly  one;  e.g., 
MDAS_CONNECT(),  MDAS_0PEN(),  MDAS.PIPEO,  etc. 

A  third  option  is  to  explicitly  narrow  the  result  to  a  single  item  according  to  some  condition 
or  criteria.  MDAS_INFO_SELECT()  is  provided  for  this  purpose.  The  use  of  this  function  is 
not  limited  to  metadata  returned  by  MDAS_INQUIRE() .  The  user  may  wish  to  input  Info 
created  at  the  user  level  or  obtained  by  other  means. 


4.7. 3.4. 5.1  MDAS  .INFO  .SELECT  ( ) 


MDAS_INFO_SELECT(inf o ,  cond,  entity,  status) 
info:  (IN/OUT)  MDAS.INFOH 

cond:  (IN)  MDAS.INFOH 

entity:  (OUT)  MDAS.INFOH 
status:  (IN/OUT)  MDAS_status 


status  codes 

type 

meaning 

MDAS.SUCCESS 

success 

entity  selected 

MDAS_WARN_INFO 

warning 

info  is  empty  or  NULL 

MDAS_WARN_COND 

warning 

cond  is  empty  or  NULL 

MDAS.ERR.INIT 

error 

MDAS  not  initialized 

MDAS_ERR_INFO 

error 

invalid  info 

MDAS_ERR_COND 

error 

invalid  cond 

MDAS_INFO_SELECT()  selects  entities  from  info  based  on  the  criteria  given  in  cond  and 
returns  a  single  item  in  entity.  Only  the  contents  of  info  are  used:  MDAS  Catalogs  are 
not  searched. 
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The  cond  argument  is  used  to  specify  conditions  and  criteria  binding  on  the  query.  The  to¬ 
kens  MDAS.CONDITION  and  MDAS_CRITERIA  are  provided  for  this  purpose  (see  section  4. 7. 2. 6). 
The  cond  argument  may  be  NULL  to  force  default  selection  rules. 

If  cond  contains  MDAS_BEST,  then  all  records  of  info  are  searched  and  default  selection  rules 
apply.  Otherwise,  MDAS.INFO_SELECT()  returns  the  first  entity  in  info  matching  all  the 
conditions  and  criteria  in  cond. 


4. 7. 3. 4. 6  Printing  Info 

4.7.3.4.6.1  MDAS_INFO-PRINT() 

MDAS.INFOJ>RIKT(info,  status) 

info:  (IN)  MDAS_INFOH 

status:  (IN/OUT)  MDAS. status 


status  codes 

type 

meaning 

MDAS.SUCCESS 

success 

info  printed 

MDAS_WARN_INFO 

warning 

info  is  empty 

MDAS_ERR_INIT 

error 

AIDAS  not  initialized 

MDAS_ERR_INFO 

error 

invalid  info 

MDAS_INFO_PRINT()  prints  the  contents  of  an  Info  structure  to  standard  output  or  the  O/S 
equivalent. 


4. 7. 3. 5  Access 

4. 7. 3. 5.1  Access  Authorization 

Applications  running  in  a  heterogeneous,  distributed  massive  data  analysis  system  may 
often  require  connections  to  resources,  methods,  and  data  sets  which  belong  to  different 
security  realms  or  domains.  Thus,  the  system  must  handle  issues  related  to  authentication 
and  security  in  this  environment.  The  ticket  model  is  used  within  MDAS.  Functionally,  this 
model  subsumes  other  security  schemes. 

The  semantics  of  tickets  is  based  on  a  point-to-point  authorization  protocol  in  which  each 
side  is  assumed  to  have  a  private  security  key  for  the  other,  plus  the  ability  to  generate 
public  “tickets”  which  can  be  decoded  by  the  other  party’s  private  key  for  access  authoriza¬ 
tion.  Under  this  model,  a  passwordless  system  can  be  considered  to  have  null  tickets.  A 
password  challenge  system  can  permit  the  instantiation  of  tickets,  where  the  user  changes 
from  a  login+password  paradigm  to  a  ticket  +  login  paradigm.  Given  the  permission  to 
execute  a  method  to  access  a  data  set  and  then  to  execute  an  analysis  or  display  method, 
AIDAS  supports  third-party  authentication  in  which  the  methods  directly  exchange  tickets 
to  validate  the  information  exchange. 
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4.7.3. 5. 1.1  MDASJTICKETO 


MDAS.TICKET ( item ,  user,  type,  ticket,  status) 


item: 

(IN) 

MDAS.INFOH 

user: 

(IN) 

MDAS.INFOH 

ttype : 

(IN) 

MDAS.INFOH 

ticket : 

(IN/OUT) 

MDAS.INFOH 

status : 

(IN/OUT) 

MDAS.status 

status  codes 

type 

meaning 

MDAS.SUCCESS 

success 

ticket  updated 

MDAS.WARN.USER 

warning 

user  is  empty  or  NULL 

MDAS.WARN.TTYPE 

warning 

ttype  is  empty  or  NULL 

MDAS.ERR.INIT 

error 

MDAS  not  initialized 

MDAS.ERR.USER 

error 

invalid  or  unknown  user 

MDAS.ERR.TTYPE 

error 

invalid  or  unknown  ttype 

MDAS.ERR.TICKET 

error 

invalid  ticket 

MDAS.ERR.MEMORY 

error 

unable  to  allocate  memory 

MDAS_TICKET()  generates  an  authorization  “ticket”  of  type  ttype  for  a  specific  item  and 
user  using  built-in  libraries  or  modules  installed  on  the  local  platform.  The  item  can  be 
a  data  set,  method,  or  resource.  The  user  and  ttype  arguments  may  reference  an  ac¬ 
tual  user  and  authorization  method,  or  NULL  may  be  supplied  to  force  default  behavior. 
Any  metadata  referenced  by  item,  user,  and  ttype  must  be  registered  in  an  accessible 
MDAS  Catalog.  If  the  descriptions  of  item,  user,  or  ttype  are  somehow  incomplete, 
MDAS.INQUIREO  and  other  Info  manipulation  procedures  may  be  called  internally  with 
default  conditions  and  criteria  to  complete  the  minimal  metadata  requirements  for  generat¬ 
ing  ticket.  MDAS.TICKET  fails  if  the  supplied  metadata  is  too  vague  or  local  methods  are 
not  found  to  enact  the  requested  authentication. 


4. 7. 3. 5. 2  Service  Connection 


4.7.3.5.2.1  MDAS_CONNECT() 


MDAS_CONNECT(server ,  ticket,  comm,  servh,  status) 


server: 

(IN/OUT) 

MDAS.INFOH 

ticket : 

(IN/OUT) 

MDAS.INFOH 

comm: 

(IN) 

handle 

servh: 

(OUT) 

MDAS.SERVH 

status : 

(IN/OUT) 

MDAS.status 
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status  codes 

type 

meaning 

MDAS.SUCCESS 

success 

connection  established 

MDAS_WARN_SERVER 

warning 

server  is  empty  or  NULL 

MDAS_WARN_TICKET 

warning 

ticket  is  empty  or  NULL 

MDAS_WARN_COMM 

warning 

comm  different  from  MDAS.INIT 

MDAS_WARN_MPI 

warning 

comm  non-NULL  but  no  MPI 

MDAS_ERR_INIT 

error 

MDAS  not  initialized 

MDAS_ERR_SERVER 

error 

invalid  or  unknown  server 

MDAS.ERR.TICKET 

error 

invalid  or  unknown  ticket 

MDAS_ERR_MEMORY 

error 

unable  to  allocate  memory 

MDAS_ERR_COMM 

error 

comm  not  part  of  MDAS.INIT  comm 

MDAS_ERR_SERVH 

error 

server  not  available 

MDAS.CONNECT ( )  connects  an  application  program  with  the  authorization  protocol  and  key 
specified  in  ticket  to  the  service  described  in  server.  If  server  contains  an  MDAS.LIST 
describing  multiple  services  then  a  single  service  will  be  selected  using  default  selection  rules. 
The  ticket  argument  may  also  contain  multiple  tickets,  in  which  case  a  match  between  one 
of  the  tickets  and  a  selected  service  will  be  attempted.  The  ticket  argument  may  be  MULL 
to  force  internal  ticket  development  with  default  selection  criteria.  If  the  descriptions  of 
server  or  ticket  are  somehow  incomplete,  MDAS_INQUIRE()  and  other  Info  manipulation 
procedures  may  be  called  internally  with  default  conditions  and  criteria  to  complete  the 
minimal  metadata  requirements  for  generating  the  connection. 

The  comm  argument  should  be  used  only  when  the  application  is  linked  to  an  MPI-enabled 
version  of  MDAS.  If  non-NULL,  comm  must  be  equivalent  to  or  “split”  (MPI_COMM_SPLIT() ) 
from  the  communicator  argument  used  in  MDAS_INIT(). 

The  returned  servh  handle  maintains  the  functionality  of  a  physical  connection  across 
time-outs. 


4.7.3. 5. 2. 2  MDAS  .DISCONNECT  (  ) 


MDAS.DISCONNECT (servh , 
servh:  (IN/OUT) 

comm:  (IN) 

status:  (IN/OUT) 


comm,  status) 
MDAS.SERVH 
MDAS.handle 
MDAS.status 


status  codes 

type 

meaning 

MDAS.SUCCESS 

success 

server  deallocated 

MDAS.WARN.COMM 

warning 

comm  different  from  MDAS.CONNECT 

MDAS. WARN. MPI 

warning 

comm  non-NULL  but  no  MPI 

MDAS.ERR.INIT 

error 

MDAS  not  initialized 

MDAS.ERR.SERVH 

error 

invalid  servh 

MDAS.ERR.MEMORY 

error 

unable  to  deallocate  memory 

MDAS.ERR.COMM 

error 

comm  not  part  of  MDAS.CONNECT 

MDAS.ERR.SERVER 

error 

server  not  available 
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MDAS.DISCONNECT ( )  closes  the  connection  specified  by  servh  (and  possibly  comm)  and  frees 
any  memory  associated  with  the  structure. 


4.7. 3. 5. 2. 3  MD  AS  .CONNECT  and  MDAS_DISCONNECT()  Example 

PROGRAM  dbconnect 

MDAS.status  status 
MDAS.INFOH  dbinfo 
MDAS.SERVH  dbh 

MDAS_INIT(argc,  argv,  NULL,  status) 

MDAS_INFO_CREATE(MDAS_RESOURCE,  dbinfo,  status) 
MDAS_INFO_SET_ATTR(MDAS_NAME,  "ord.com",  dbinfo,  status) 
MDAS_INFO_SET_ATTR(MDAS_RSRC_SRVN ,  "illustra",  dbinfo,  status) 
MDAS.CONNECT (dbinfo,  NULL,  NULL,  servh,  status) 

MDAS_DISCONNECT( servh,  NULL,  status) 

MDAS_FINALIZE(NULL , status) 

END  PROGRAM 


4. 7. 3. 6  Operations  on  Data  Sets 


4. 7. 3.6.1  Cache  Operations 


4.7.3.6.1.1  MDASjGETO 


MDAS_GET(dset ,  cache, 
dset :  (IN/OUT) 

cache:  (IN/OUT) 

status:  (IN/OUT) 


status) 

MDAS.INFOH 

MDAS.INFOH 

MDAS.status 
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status  codes 

type 

meaning 

MDAS.SUCCESS 

success 

dset  cached 

MDAS_WARN_CACHE 

warning 

cache  is  empty  or  NULL 

MDAS.ERR.INIT 

error 

MDAS  not  initialized 

MDAS_ERR_DSET 

error 

invalid  dset 

MDAS_ERR_CACHE 

error 

invalid  cache 

MDAS_ERR_MEMORY 

error 

unable  to  allocate  memory 

MDAS_ERR_READ 

error 

read  access  denied 

MDAS.ERR. WRITE 

error 

write  access  denied 

MDAS.ERR.IO 

error 

unable  to  perform  I/O 

MDAS_GET()  retrieves  a  data  set  specified  in  dset  and  caches  it  on  the  local  file  system. 
Any  required  tickets  and/or  connections  are  automatically  generated.  The  target  location 
is  selected  by  the  MDAS  library  and  returned  in  cache.  The  user  can  specify  alternate 
formats  for  the  storage  of  dset  in  cache  on  input.  The  MDAS  library  may  invoke  a  3rd 
party  mover  to  perform  the  data  transfer  and  possibly  spool  the  data.  If  cache  contains 
a  named  data  set,  then  the  operation  of  MDAS_GET()  will  be  functionally  equivalent  to 
MDAS_INFO_PIPE().  If  the  description  of  dset  is  somehow  incomplete,  MDAS.IWQUIREQ 
and  other  Info  manipulation  procedures  may  be  called  internally  with  default  conditions 
and  criteria  to  complete  the  minimal  metadata  requirements  for  identifying  the  data  set. 


4. 7.3. 6. 1.2  MDAS_GETALL() 


MDAS_GETALL(dset ,  cache,  status) 
dset:  (IN/OUT)  MDAS.INFOH 

cache:  (IN/OUT)  MDAS.INFOH 
status:  (IN/OUT)  MDAS.status 


status  codes 

type 

meaning 

MDAS.SUCCESS 

success 

data  sets  cached 

MDAS.WARN.CACHE 

warning 

cache  is  empty  or  NULL 

MDAS.ERR.INIT 

error 

MDAS  not  initialized 

MDAS_ERR_DSET 

error 

invalid  dset 

MDAS.ERR.CACHE 

error 

invalid  cache 

MDAS.ERR.MEMORY 

error 

unable  to  allocate  memory 

MDAS.ERR.READ 

error 

read  access  denied 

MDAS.ERR. WRITE 

error 

write  access  denied 

MDAS.ERR.IO 

error 

unable  to  perform  I/O 

MDAS_GETALL()  retrieves  a  set  of  data  sets  specified  in  dset  and  caches  them  on  the  local 
file  system.  The  entity  type  of  dset  may  be  either  MDAS.DATASET  or  MDAS.LIST.  The  cache 
argument  may  not  specify  more  than  one  resource  and  may  not  name  any  data  set(s). 
MDAS_GETALL()  is  otherwise  equivalent  to  MDAS_GET(). 
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4.7. 3.6. 1.3  MDAS-PUTO 


MDAS_PUT(dset,  rsrc, 
dset :  (IN/OUT) 

rsrc:  (IN/OUT) 

status:  (IN/OUT) 


status) 

MDAS.INFOH 

MDAS.INFOH 

MDAS.status 


status  codes 

type 

meaning 

MDAS.SUCCESS 

success 

dset  stored  in  rsrc 

MDAS.WARN.RESOURCE 

warning 

rsrc  is  empty  or  NULL 

MDAS.ERR.INIT 

error 

MDAS  not  initialized 

MDAS.ERR.DSET 

error 

invalid  dset 

MDAS.ERR.RESOURCE 

error 

invalid  rsrc 

MDAS.ERR.MEMORY 

error 

unable  to  allocate  memory 

MDAS.ERR.READ 

error 

read  access  denied 

MDAS.ERR.WRITE 

error 

write  access  denied 

MDAS.ERR.IO 

error 

unable  to  perform  I/O 

MDAS_PUT()  retrieves  a  data  set  specified  in  dset  from  local  cache  and  moves  it  to  the 
resource  specified  by  rsrc.  The  target  location  is  selected  by  the  MDAS  library  and  returned 
in  rsrc.  The  user  can  also  use  rsrc  to  specify  alternate  formats  and  storage  servers  for 
the  storage  of  dset.  The  MDAS  library  may  invoke  a  3rd  party  mover  to  perform  the  data 
transfer  and  possibly  spool  the  data.  If  rsrc  contains  a  named  data  set,  then  the  operation 
of  MDAS.PUTO  will  be  functionally  equivalent  to  MDAS_INFO_PIPE() .  If  the  descriptions 
of  dset  or  rsrc  are  somehow  incomplete,  MDAS_INQUIRE()  and  other  Info  manipulation 
procedures  may  be  called  internally  with  default  conditions  and  criteria  to  complete  the 
minimal  metadata  requirements  for  identifying  the  data  set  and  resource. 


4. 7. 3.6. 1.4  MDAS-PUTALLO 


MDAS_PUTALL(dset ,  rsrc,  status) 


dset:  (IN/OUT) 
rsrc:  (IN/OUT) 
status:  (IN/OUT) 


MDAS.INFOH 

MDAS.INFOH 

MDAS.status 


status  codes 

type 

meaning 

MDAS.SUCCESS 

success 

dset  stored  in  rsrc 

MDAS.WARN.RESOURCE 

warning 

rsrc  is  empty  or  NULL 

MDAS.ERR.INIT 

error 

MDAS  not  initialized 

MDAS.ERR.DSET 

error 

invalid  dset 

MDAS.ERR.RESOURCE 

error 

invalid  rsrc 

MDAS.ERR.MEMORY 

error 

unable  to  allocate  memory 

MDAS.ERR.READ 

error 

read  access  denied 

MDAS.ERR.WRITE 

error 

write  access  denied 

MDAS.ERR.IO 

error 

unable  to  perform  I/O 
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MDAS_PUTALL()  retrieves  a  set  of  data  sets  specified  in  dset  from  local  cache  and  moves 
them  to  the  resource  specified  by  rsrc.  The  entity  type  of  dset  may  be  either  MDAS.DATASET 
or  MDAS.LIST.  The  rsrc  argument  may  not  specify  more  than  one  resource  and  may  not 
name  any  data  set(s).  MDAS_PUTALL()  is  otherwise  equivalent  to  MDAS_PUT(). 


4. 7.3.6. 1.5  MDAS_GET()  Example 

PROGRAM  getk2 

MDAS_status  status 
MDAS_INFOH  dsinfo,  cacheinfo 

MDAS_INIT(argc,  argv,  NULL,  status) 

MDAS_INFO_CREATE(MDAS_DATASET,  dsinfo,  status) 
MDAS_INFO_SET_ATTR(MDAS_NAME,  "fin.dat",  dsinfo,  status) 
MDAS_INFO_CREATE (MDAS.DATASET ,  cacheinfo,  status) 
MDAS_INFO_SET_ATTR(MDAS_STOR_FMTN ,  "khoros2",  cacheinfo,  status) 
MDAS.GET (dsinfo,  cacheinfo,  status) 

MDAS_FINALIZE(NULL, status) 

END  PROGRAM 


4. 7. 3. 6. 2  Generalized  Point-to-Point  Dataflow 

MDAS  provides  a  generalization  of  the  l  n i x  “pipe”  paradigm  for  data  set  transimission. 
The  operation  may  be  performed  on  either  open  data,  handles  or  data  sets  described  by 
metadata  in  Info  structures.  Since  MDAS_INFO_PIPE()  allows  the  MDAS  Library  (and 
any  schedulers  known  or  discovered  by  the  library)  to  select  resources,  tickets,  and  meth¬ 
ods  for  completing  the  pipe  transaction,  it  provides  the  greatest  opportunities  for  MDAS 
optimization  of  any  point-to-point  data  transfer  request. 


4. 7.3. 6.2.1  MDAS_INFO_PIPE() 


MDAS_INFO_PIPE(inf ol , 
infol:  (IN/OUT) 

inf o2:  (IN/OUT) 
status:  (IN/OUT) 


info2,  status) 
MDAS.INFOH 
MDAS.INFOH 
MDAS.status 
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status  codes 

type 

meaning 

MDAS.SUCCESS 

success 

pipe  completed 

MDAS_WARN_READ 

warning 

source  automatically  selected 

MDAS.WARN.WRITE 

warning 

target  automatically  selected 

MDAS .WARN. 10 

warning 

3rd  party  mover  employed 

MDAS.WARN.FORMAT 

warning 

format  conversion  performed 

MDAS.ERR.INIT 

error 

MDAS  not  initialized 

MDAS.ERR.INF01 

error 

invalid  infol 

MDAS.ERR.INF02 

error 

invalid  info2 

MDAS_ERR_READ 

error 

read  access  denied 

MDAS.ERR.WRITE 

error 

write  access  denied 

MDAS_ERR_MEMORY 

error 

unable  to  allocate  memory 

MDAS.ERR.IO 

error 

unable  to  perform  I/O 

MDAS_ERR_FORMAT 

error 

unable  to  convert  format 

MDAS_INFO_PIPE()  takes  two  MDAS  MDAS.info  structures— each  containing  references  to 
data  sets,  and  “pipes”  the  contents  of  a  single  data  set  from  the  first  MDAS_info  structure 
to  a  single  data  set  in  the  second.  If  infol  contains  records  describing  multiple  data  sets 
then  a  single  data  set  will  be  selected  using  default  selection  rules.  The  info2  argument 
may  also  contain  multiple  data  sets,  in  which  case  a  single  data  set  will  be  selected.  Any 
required  tickets  and/or  connections  are  automatically  generated. 

If  the  descriptions  of  the  (selected)  data  sets  in  infol  or  info2  are  somehow  incomplete, 
MDAS.INQUIREO  and  other  Info  manipulation  procedures  may  be  called  internally  with  de¬ 
fault  conditions  and  criteria  to  complete  the  minimal  metadata  requirements  for  completing 
the  “pipe”  transaction.  The  call  fails  when  choices  are  ambiguous.  The  call  is  otherwise 
functionally  equivalent  to  MDAS_DATAH_PIPE() . 


4.7. 3.6. 2. 2  MDAS_DATAH_PIPE() 


MDAS_DATAH_PIPE(dhl ,  dh2,  status) 


dhl : 
dh2 : 
status : 


(IN/OUT) 

(IN/OUT) 

(IN/OUT) 


MDAS.DATAH 

MDAS.DATAH 

MDAS_status 
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status  codes 

type 

meaning 

MDAS.SUCCESS 

success 

stream  dhl  piped  to  stream  dh2 

MDAS_WARN_EOF 

warning 

dhl  already  at  EOF 

MDAS_WARN_IO 

warning 

3rd  party  mover  employed 

MDAS_WARN_FORMAT 

warning 

format  conversion  performed 

MDAS_ERR_IMIT 

error 

MDAS  not  initialized 

MDAS_ERR_DH1 

error 

invalid  dhl 

MDAS_ERR_DH2 

error 

invalid  dh2 

MDAS.ERR.READ 

error 

dhl  closed 

MDAS_ERR_WRITE 

error 

dh2  closed 

MDAS.ERR.MEMORY 

error 

unable  to  allocate  memory 

MDAS_ERR_IO 

error 

unable  to  perform  I/O 

MDAS_ERR_FORMAT 

error 

unable  to  convert  format 

MDAS_DATAH_PIPE()  takes  two  MDAS  data  handles — one  open  for  read  and  the  other  for 
write,  and  ‘‘pipes”  the  data  from  one  to  the  other  performing  any  stream  and  format 
conversion  in-situ.  Third-party  movers  are  employed  if  necessary.  The  operation  begins  at 
the  current  stream  locations  in  dhl  and  dh2.  The  call  may  fail  if  no  movers  are  available  to 
perform  the  required  operation(s).  Both  handles  are  open  on  successful  return  but  assumed 
to  be  at  “end  of  stream”. 


4. 7.3. 6. 2.3  MDAS_INF0 JPIPEO  Example 

PROGRAM  pipefun 

MDAS_status  status 
MDAS_INFOH  funinfo,  psinfo 

MDAS_INIT(argc,  argv,  MULL,  status) 

MDAS_INFO_CREATE (MDAS.DATASET ,  funinfo,  status) 
MDAS_INFO_SET_ATTR(MDAS_NAME,  "fun. dat" ,  funinfo ,  status) 

MDAS_INFO_CREATE(MDAS_RESOURCE,  psinfo,  status) 
MDAS_INFO_SET_ATTR(MDAS_RSRC_TYPE,  MDAS^PRINTER,  psinfo,  status) 
MDAS_INFCLSET_ATTR(MDAS_RSRC_FMTN,  "postscript",  psinfo,  status) 

MDAS_INFO_PIPE(funinf o ,  psinfo ,  status) 
print  "fun. dat  printed  at:" 

MDAS_INFO_PRINT (psinfo , status) 

MDAS_FINALIZE(NULL , status) 

END  PROGRAM 
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4. 7. 3. 6. 2. 4  MDAS_DATAH_PIPE()  Example 


PROGRAM  pipestream 

MDAS_status  status 
MDAS.INFOH  f ininfo,  tailinfo 
MDAS.DATAH  finh,  tailh 

MDAS_INIT(argc,  argv,  NULL,  status) 

MDAS_INFO_CREATE (MDAS.DATASET ,  fininfo,  status) 
MDAS_INFO_SET_ATTR(MDAS_NAME ,  "fin.dat",  fininfo,  status) 
MDAS_0PEN (NULL ,  NULL,  fininfo,  NULL,  finh,  status) 

MDAS_INFO_CREATE(MDAS_DATASET,  tailinfo,  status) 
MDAS_INFO_SET_ATTR(MDAS_NAME ,  "tail.dat",  tailinfo,  status) 
MDAS.OPEN (NULL ,  NULL,  tailinfo,  NULL,  finh,  status) 

MDAS_DATAH_PIPE(f inh,  tailh,  status) 

MDAS_CLOSE(f inh,  NULL,  status) 

MDAS_CLOSE(tailh,  NULL,  status) 

MDAS_FINALIZE(NULL, status) 

END  PROGRAM 


4. 7. 3.6. 3  Generalized  Data  Set  Scatter/Gather 


MDAS  supplies  multiplex  versions  of  the  MDAS_*_PIPE()  commands  for  the  replication  and 
concatenation  of  multiple  data  sets. 

* 

4.7. 3.6.3. 1  MDAS_INFO_SCATTER() 


MDAS_INFO_SCATTER(infol ,  info2,  status) 
infol:  (IN/OUT)  MDAS.INFOH 
inf o2 :  (IN/OUT)  MDAS.INFOH 
status:  (IN/OUT)  MDAS_status 


status  codes 

type 

meaning 

MDAS.SUCCESS 

success 

scatter  completed 

MDAS_WARN_READ 

warning 

source  automatically  selected 

MDAS_WARN_WRITE 

warning 

target  automatically  selected 

MDAS_WARN_IO 

warning 

3rd  party  mover  employed 

MDAS_WARN_FORMAT 

warning 

format  conversion  performed 

MDAS.ERR.IMIT 

error 

MDAS  not  initialized 

MDAS_ERR_INF01 

error 

invalid  infol 

MDAS_ERR_INF02 

error 

invalid  info2 

MDAS_ERR_READ 

error 

read  access  denied 

MDAS.ERR.WRITE 

error 

write  access  denied 

MDAS_ERR_MEMORY 

error 

unable  to  allocate  memory 

MDAS.ERR.IO 

error 

unable  to  perform  I/O 

MDAS_ERR_FORMAT 

error 

unable  to  convert  format 

MDAS_INFO_SCATTER()  replicates  the  contents  of  a  single  data  set  specified  in  infol  to  one 
or  more  data  sets  referenced  in  inf o2.  The  result  is  that  the  contents  of  a  data  set  in  infol 
are  replicated  to  one  or  more  data  sets  in  info2.  If  infol  contains  records  describing 
multiple  data  sets  then  a  single  data  set  will  be  selected  using  default  selection  rules.  If 
info2  contains  multiple  data  sets,  all  will  be  selected  as  targets.  Any  required  tickets 
and/or  connections  are  automatically  generated. 

If  the  descriptions  of  the  (selected)  data  sets  in  infol  or  info2  are  somehow  incomplete, 
MDAS_INQUIRE()  and  other  Info  manipulation  procedures  may  be  called  internally  with  de¬ 
fault  conditions  and  criteria  to  complete  the  minimal  metadata  requirements  for  completing 
the  “scatter  ’  transaction.  The  call  fails  when  choices  are  ambiguous,  access  authorization 
is  denied,  or  when  proper  read/write  modes  can  not  be  established.  The  call  is  otherwise 
functionally  equivalent  to  MDAS_DATAH_SCATTER() . 


4. 7.3. 6.3. 2  MDAS_I NFO .GATHER  (  ) 


MDAS_INFO_GATHER(inf ol ,  info2,  status) 
infol:  (IN/OUT)  MDAS.INFOH 
info2:  (IN/OUT)  MDAS.INFOH 

status:  (IN/OUT)  MDAS.status 
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status  codes 

type 

meaning 

MDAS.SUCCESS 

success 

gather  completed 

MDAS_WARN_READ 

warning 

source  automatically  selected 

MDAS_WARN_WRITE 

warning 

target  automatically  selected 

MDAS.WARN.IO 

warning 

3rd  party  mover  employed 

MDAS_WARN_FORMAT 

warning 

format  conversion  performed 

MDAS.ERR.INIT 

error 

MDAS  not  initialized 

MDAS.ERR.INFOi 

error 

invalid  infol 

MDAS_ERR_INF02 

error 

invalid  info2 

MDAS_ERR_READ 

error 

read  access  denied 

MDAS.ERR.WRITE 

error 

write  access  denied 

MDAS_ERR_MEMORY 

error 

unable  to  allocate  memory 

MDAS_ERR_IO 

error 

unable  to  perform  I/O 

MDAS_ERR_FORMAT 

error 

unable  to  convert  format 

MDAS_INFO_GATHER()  pipes  the  contents  of  one  or  more  data  sets  referenced  in  infol  to  a 
single  data  set  specified  in  inf o2.  The  result  is  that  the  contents  of  the  data  sets  in  infol 
are  concatenated  (in  list  order)  to  the  data  set  in  info2.  If  infol  contains  multiple  data 
sets,  all  will  be  selected  as  sources.  If  inf  o2  contains  records  describing  multiple  data  sets 
then  a  single  data  set  will  be  selected  using  default  selection  rules.  Any  required  tickets 
and/or  connections  are  automatically  generated. 


If  the  descriptions  of  the  (selected)  data  sets  in  infol  or  info2  are  somehow  incomplete, 
MDAS_INQUIRE()  and  other  Info  manipulation  procedures  may  be  called  internally  with  de¬ 
fault  conditions  and  criteria  to  complete  the  minimal  metadata  requirements  for  completing 
the  "gather’  transaction.  The  call  fails  when  choices  are  ambiguous,  access  authorization 
is  denied,  or  when  proper  read/write  modes  can  not  be  established.  The  call  is  otherwise 
functionally  equivalent  to  MDAS_DATAH_GATHER() . 


4. 7. 3. 6. 3. 3  MDAS_DATAH_SCATTER() 


MDAS_DATAH_SCATTER(dh,  count,  dhvect,  status) 


dh: 

count : 
dhvect : 
status : 


(IN/OUT) 

(IN) 

(IN/OUT) 

(IN/OUT) 


MDAS.DATAH 

integer 

vector  of  MDAS.DATAH 
MDAS_status 
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status  codes 

type 

meaning 

MDAS.SUCCESS 

success 

dh  piped  to  dhvect 

MDAS.WARN.EOF 

warning 

dh  already  at  EOF 

MDAS_WARN_IO 

warning 

3rd  party  mover  employed 

MDAS_WARN_FORMAT 

warning 

format  conversion  performed 

MDAS.ERR.INIT 

error 

MDAS  not  initialized 

MDAS_ERR_DH 

error 

invalid  dh 

MDAS.ERR.COUNT 

error 

invalid  count 

MDAS.ERR.DHVECT 

error 

invalid  dhvect 

MDAS_ERR_READ 

error 

dh  closed 

MDAS_ERR_WRITE 

1  error 

handle  in  dhvect  closed 

MDAS.ERR.MEMORY 

error 

unable  to  allocate  memory 

MDAS.ERR.IO 

error 

unable  to  perform  I/O 

MDAS_ERR_FORMAT 

error 

unable  to  convert  format 

MDAS.DATAH. SCATTER ()  pipes  the  contents  of  the  data  stream  pointed  to  by  dh  to  a  vector  of 
distinct  streams  dhvect  of  size  count.  The  operation  begins  at  the  current  stream  locations 
in  dh  and  dhvect.  The  result  is  that  the  (remaining)  stream  contents  of  dh  are  replicated  to 
the  streams  in  dhvect.  Upon  successful  return,  all  data  handles  will  be  open  but  assumed 
to  be  at  “end  of  stream”.  Read  mode  must  be  enabled  for  dh  and  all  data  handles  in  dhvect 
must  be  enabled  for  write. 


4. 7.3. 6. 3.4  MDAS_D  ATAH.GATHER  ( ) 


MDAS_DATAH_GATHER(count ,  dhvect,  dh,  status) 
count :  ( IN )  int  eger 

dhvect:  (IN/OUT)  vector  of  MDAS.DATAH 
dh:  (IN/OUT)  MDAS.DATAH 

status:  (IN/OUT)  MDAS. status 


status  codes 

type 

meaning 

MDAS.SUCCESS 

success 

dhvect  concatenated  to  dh 

MDAS_WARN_EOF 

warning 

some  dhvect  handles  at  EOF 

MDAS. WARN. 10 

warning 

3rd  party  mover  employed 

MDAS.WARN.FORMAT 

warning 

format  conversion  performed 

MDAS.ERR.INIT 

error 

MDAS  not  initialized 

MDAS.ERR.COUNT 

error 

invalid  count 

MDAS.ERR.DHVECT 

error 

invalid  dhvect 

MDAS.ERR.DH 

error 

invalid  dh 

MDAS.ERR.READ 

error 

handle  in  dhvect  closed 

MDAS.ERR. WRITE 

error 

dh  closed 

MDAS.ERR.MEMORY 

error 

unable  to  allocate  memory 

MDAS.ERR.IO 

error 

unable  to  perform  I/O 

MDAS.ERR.FORMAT 

error 

unable  to  convert  format 
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MDAS_DATAH_GATHER  ( )  pipes  the  contents  of  the  distinct  data  streams  pointed  to  by  dhvect 
of  size  count  to  the  stream  dh.  The  operation  begins  at  the  current  stream  locations  in 
dhvect  and  dh.  The  result  is  that  the  (remaining)  stream  contents  of  dhvect  are  concate¬ 
nated  to  the  stream  in  dh  in  vector  order.  Upon  successful  return,  all  data  handles  will 
be  open  but  assumed  to  be  at  “end  of  stream”.  Read  mode  must  be  enabled  for  all  data 
handles  in  dhvect  and  dh  must  be  enabled  for  write. 


4. 7. 3. 6.4  Generalized  Open  on  Data  Sets 


4. 7. 3. 6.4.1  MDAS_0PEN() 


MDAS_OPEN(servh,  comm. 


servh: 

(IN) 

coirun: 

(IN) 

dset : 

(IN) 

mode: 

(IN) 

dh: 

(OUT) 

status : 

(IN/OUT) 

dset,  mode,  dh,  status) 

MDAS.SERVH 

MDAS.handle 

MDAS.INFOH 

MDAS.INFOH 

MDAS.DATAH 

MDAS_status 


status  codes 

type 

meaning 

MDAS.SUCCESS 

success 

data  set  open  on  dh 

MD  AS  _  W  ARN  _  SERVH 

warning 

servh  is  empty  or  NULL 

MDAS_WARN_SERVER 

warning 

server  automatically  selected 

MDAS. WARN. COMM 

warning 

comm  different  from  MDAS. CONNECT 

MDAS. WARN. MPI 

warning 

comm  non- NULL  but  no  MPI 

MDAS. WARN. DSET 

warning 

dset  is  empty  or  NULL 

MDAS_WARN_DATASET 

warning 

data  set  automatically  selected 

MDAS_WARN_M0DE 

warning 

mode  is  empty  or  NULL 

MDAS.WARN.IO 

warning 

I/O  mode  automatically  selected 

MDAS_ERR_INIT 

error 

MDAS  not  initialized 

MDAS_ERR_SERVH 

error 

invalid  servh 

MDAS_ERR_C0MM 

error 

comm  not  part  of  MDAS. CONNECT 

MDAS_ERR_DSET 

error 

invalid  dset 

MDAS_ERR_M0DE 

error 

invalid  mode 

MDAS_ERR_READ 

error 

read  access  denied 

MDAS_ERR_ WRITE 

error 

write  access  denied 

MDAS_ERR_MEMORY 

error 

unable  to  allocate  .memory 

MDAS.ERR.SERVER 

error 

server  not  available 

MDAS_ERR_DATASET 

error 

data  set  not  available 

MDAS.0PENO  opens  a  generalized  data  handle  for  a  data  set  specified  in  the  dset  argu¬ 
ment.  If  servh  is  NULL,  then  the  metadata  specified  in  dset  are  used  to  establish  access 
authentication  and  a  service  connection  to  a  resource  containing  the  data  set.  The  comm 
argument  is  used  only  when  the  application  is  linked  to  an  MPI-enabled  version  of  MDAS; 
it  is  otherwise  ignored.  If  comm  is  used,  it  must  be  equivalent  or  “split”  from  the  MPI 
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communicator  used  to  create  servh.  This  behavior  is  guaranteed  when  servh  is  NULL.  The 
MDAS  mode  argument  should  be  either  NULL  for  default  read/write  access  or  contain  an 
I/O  directive  attribute. 


A  warning  is  returned  in  status  if  NULL  is  passed  but  the  data  set  access  mode  is  limited  to 
one  of  read  or  write.  An  error  is  returned  with  a  NULL  dh  when  access  to  the  data  set  is  de¬ 
nied.  If  the  descriptions  of  servh,  dset,  or  mode  are  somehow  incomplete,  MDAS_INQUIRE() 
and  other  Info  manipulation  procedures  may  be  called  internally  with  default  conditions 
and  criteria  to  complete  the  minimal  metadata  requirements  for  opening  the  data  handle.  If 
successful,  the  returned  handle  contains  Info  from  dset  and  a  pointer  to  the  actual  physical 
data  stream  employed. 


4.7.3. 6.4.2  MDAS_CLOSE() 

MDAS_CLOSE(dh,  comm,  status) 

dh:  (IN/OUT)  MDAS.DATAH 

comm:  (IN)  MDAS_handle 

status:  (IN/OUT)  MDAS.status 


status  codes 

type 

meaning 

MDAS.SUCCESS 

success 

dh  deallocated 

MDAS.WARN.COMM 

warning 

comm  different  from  MDAS.OPEN 

MDAS.WARN_.MPI 

warning 

comm  non-NULL  but  no  MPI 

MDAS.ERR.INIT 

error 

MDAS  not  initialized 

MDAS. ERR. DH 

error 

invalid  dh 

MDAS.ERR.COMM 

error 

comm  not  part  of  MDAS. OPEN 

MDAS.ERR. MEMORY 

error 

unable  to  deallocate  memory 

MDAS.ERR.SERVER 

error 

server  not  available 

MDAS.ERR.IO 

error 

I/O  error  on  close 

MDAS_CLOSE()  closes  the  data  stream,  etc.  specified  by  dh  (and  possibly  comm)  and  frees 
any  memory  associated  with  the  structure. 


4. 7.3. 6.4. 3  Example  use  of  MDASJDPENQ  and  MDAS_CLOSE() 


PROGRAM  openfinh 

MDAS.status  status 
MDAS.INFOH  dsinfo 
MDAS.DATAH  finh 


MDAS_INIT(argc,  argv,  NULL,  status) 
MDAS_INFO_CREATE(MDAS_DATASET,  dsinfo,  status) 
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MDAS_INFO_SET_ATTR(MDAS_NAME,  "fin.dat",  dsinfo,  status) 
MDAS_INFO_SET_ATTR(MDAS_STOR_FMT,  "hdf",  dsinfo,  status) 

MDAS_0PEN (NULL ,  NULL,  dsinfo,  NULL,  finh,  status) 

MDAS_CLOSE(f inh,  NULL,  status) 

MDAS_FINALIZE(NULL, status) 

END  PROGRAM 

4. 7.3.7  Block  I/O 

MDAS  supplies  MDAS_READ()  and  MDAS_WRITE()  for  block  I/O  on  data  handles.  The  de¬ 
velopment  of  spooler  daemons  are  one  example  use. 

MDAS_READ(dh,  type,  count,  buffer,  status) 


dh: 

(IN/OUT) 

MDAS.DATAH 

type : 

(IN) 

MDAS_datatype 

count : 

(IN) 

integer 

buffer: 

(OUT) 

MDAS.handle  (user  defined  buffer) 

status : 

(IN/OUT) 

MDAS_status 

.WRITE (type,  count 

,  buffer,  dh,  status) 

type : 

(IN) 

MDAS_datatype 

count : 

(IN) 

integer 

buffer: 

(IN) 

MDAS_handle  (user  defined  buffer) 

dh: 

(IN/OUT) 

MDAS.DATAH 

status : 

(IN/OUT) 

MDAS.status 

The  argument  lists  to  MDAS_READ  and  MDAS_WRITE  differ  only  in  the  order  of  arguments. 
Valid  type  values  are  given  in  table  4.5.  The  count  specifies  how  many  of  the  given  type 
are  contiguously  packed  in  the  given  buffer.  All  data  supplied  in  buffer  by  MDAS_READ() 
will  be  packed.  For  MDAS_WRITE(),  if  type  is  an  MDAS_INFOH,  MDAS_TABLE_HANDLE.  or 
MDAS.INFOH,  a  handle  packed  by  MDAS_HANDLE_PACK()  must  be  supplied  in  buffer. 

4. 7.3.7. 1  Data  Handle  Conversion 

MDAS  provides  several  data  handle  conversion  routines  to  permit  native  protocol  transac¬ 
tions  on  data  sets  opened  by  MDAS.OPENQ.  For  example,  it  is  desirable  in  data  mining  and 
knowledge  building  applications  to  search  (inquire)  about  data  sets  available  for  access  with 
a  file  stream  interface  and  then  perform  operations  on  those  data  sets.  Conversions  to  data 
handles  are  also  permitted  in  the  event  that  a  user  wishes  to  perform  MDAS_DATAH_PIPE() 
on  an  “unregistered”  data  set.  In  particular:  data  received  in  a  C  program  from  standard 
input  outside  the  purview  of  MDAS  cannot  be  registered. 
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4.7.3.7.1.1  MDAS_CVT_DH_U() 


MDAS_CVT_DH_U(dh,  unit,  status) 
dh:  (IN/ OUT)  MDAS.DATAH 

unit:  (IN/OUT)  integer 

status:  (IN/OUT)  MDAS.status 


status  codes 

type 

meaning 

MDAS .SUCCESS 

MDAS.WARN.IO 

MDAS.ERR.INIT 

MDAS.ERR.DH 

MDAS.ERR.MEMORY 

MDAS.ERR.IO 

MDAS.ERR.UNIT 

success 

warning 

error 

error 

error 

error 

error 

unit  assigned  for  dh 

3rd  party  mover  employed 
MDAS  not  initialized 
invalid  dh 

unable  to  allocate  memory 
unable  to  convert  I/O  stream 
unable  to  assign  to  given  unit 

MDAS_CVT_DH_U()  is  most  applicable  to  Fortran  implementations.  If  the  caller  supplies 
unit  <  1,  then  a  unit  number  is  selected  and  returned.  The  user  should  not  call  Fortran 
close ()  on  unit.  To  close  the  stream,  use  MDAS_CLOSE()  on  the  original  dh. 


4.7.3.7.1.2  MDAS_CVT_DH_FP() 

MDAS_CVT_DH_FP (dh ,  fp,  status) 

dh:  (IN/OUT)  MDAS.DATAH 

fp:  (OUT)  MDAS.handle 

status:  (IN/OUT)  MDAS.status 


status  codes 

type 

meaning 

MDAS. SUCCESS 

success 

f p  created  for  dh 

MDAS.WARN.IO 

warning 

3rd  party  mover  employed 

MDAS.ERR.INIT 

error 

MDAS  not  initialized 

MDAS.ERR.DH 

error 

invalid  dh 

MDAS.ERR.MEMORY 

error 

unable  to  allocate  memory 

MDAS.ERR.IO 

error 

unable  to  convert  I/O  stream 

MDAS.CVT.DH.FPO  is  most  applicable  to  ANSI  C  implementations.  The  returned  (FILE*)  fp 
is  also  cached  on  dh.  The  user  should  not  call  C  fcloseQ  on  fp.  To  close  the  stream,  use 
MDAS.CL0SEO  on  the  original  dh. 


4. 7. 3. 7. 1.3  MDAS_CVT_DH_FS() 

MDAS_CVT_DH_FS(dh,  fs,  status) 

dh:  (IN/OUT)  MDAS.DATAH 
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f s :  (OUT)  MDAS.handle 

status:  (IN/OUT)  MDAS_status 


status  codes 

type 

meaning 

MDAS.SUCCESS 

success 

f  s  created  for  dh 

MDAS.WARN.IO 

warning 

3rd  party  mover  employed 

MDAS.ERR.INIT 

error 

MDAS  not  initialized 

MDAS.ERR.DH 

error 

invalid  dh 

MDAS.ERR.MEMORY 

error 

unable  to  allocate  memory 

MDAS.ERR.IO 

error 

unable  to  convert  I/O  stream 

MDAS_CVT_DH_FS()  creates  an  open  socket  fs  for  the  stream  in  dh.  The  user  should  not 
call  manually  close  fs,  but  rather  use  MDAS.CLOSEQ  on  the  original  dh. 


4.7.3.7.1.4  MDAS_CVT_U_DH() 


MDAS_CVT_U_DH(unit ,  dh,  status) 
unit:  (IN)  integer 

dh:  (OUT)  MDAS.DATAH 

status:  (IN/OUT)  MDAS.status 


status  codes 

type 

meaning 

MDAS.SUCCESS 

success 

dh  created  for  unit 

MDAS.WARN.IO 

warning 

3rd  party  mover  employed 

MDAS.ERR.INIT 

error 

MDAS  not  initialized 

MDAS.ERR.DH 

error 

invalid  dh 

MDAS.ERR.UNIT 

error 

invalid  unit 

MDAS.ERR.MEMORY 

error 

unable  to  allocate  memory 

MDAS.ERR.IO 

error 

unable  to  convert  I/O  stream 

MDAS_CVT_U_DH()  is  most  applicable  to  Fortran  implementations.  The  caller  must  supply 
an  valid  unit  number  to  an  open  file  or  stream.  To  close  the  data  handle  and  stream,  the 
user  should  first  call  MDAS_CLOSE()  on  dh  (which  will  only  deallocate  the  data  handle)  and 
then  call  Fortran  close ()  on  on  the  original  unit. 


4. 7.3.7. 1.5  MDAS_CVT_FP_DH() 


MDAS_CVT_FP_DH (f p ,  dh, 
fp:  (IN) 

dh:  (OUT) 

status:  (IN/OUT) 


status) 

MDAS.handle 

MDAS.DATAH 

MDAS.status 
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status  codes 

type 

meaning 

MDAS.SUCCESS 

MDAS_WARN_IO 

MDAS.ERR.INIT 

MDAS_ERR_DH 

MDAS_ERR_MEMORY 

MDAS_ERR_IO 

success 

warning 

error 

error 

error 

error 

dh  created  for  f  p 

3rd  party  mover  employed 
MDAS  not  initialized 
invalid  dh 

unable  to  allocate  memory 
unable  to  convert  I/O  stream 

MDAS_CVT_FP_DH()  is  most  applicable  to  C  and  C++  implementations.  The  caller  must 
supply  an  valid  file  handle  fp  to  an  open  file  or  stream.  To  close  the  data  handle  and 
stream,  the  user  should  first  call  MDAS_CLOSE()  on  dh  (which  will  only  deallocate  the  data 
handle)  and  then  call  C  fcloseQ  on  on  the  original  fp. 


4.7.3.7.1.6  MDAS_CVT_FS_DH() 


MDAS_CVT_FS_DH(f s ,  dh, 
fs:  (IN) 

dh:  (OUT) 

status:  (IN/OUT) 


status) 

MDAS_handle 

MDAS.DATAH 

MDAS_status 


status  codes 

type 

meaning 

MDAS.SUCCESS 

success 

dh  created  for  f  s 

MDAS_WARN_IO 

warning 

3rd  party  mover  employed 

MDAS.ERR.INIT 

error 

MDAS  not  initialized 

MDAS.ERR.DH 

error 

invalid  dh 

MDAS.ERR.MEMORY 

error 

unable  to  allocate  memory 

MDAS.ERR.IO 

error 

unable  to  convert  I/O  stream 

MDAS_CVT_DH_FP ( )  creates  a  data  handle  for  the  open  socket  fs.  The  caller  must  supply 
an  valid  socket  handle  f  s  to  an  open  stream.  To  close  the  data  handle  and  stream,  the  user 
should  first  call  MDAS_CLOSE()  on  dh  (which  will  only  deallocate  the  data  handle)  and  then 
call  closeQ  on  on  the  original  fs. 


4. 7.3. 7.1. 7  MDAS_CVT_FP_DH()  Example 

/*  PROGRAM  cvtfp  —  ANSI  C  */ 
main(argc,  argv)  ; 

FILE*  fp  ; 

mdasC.status  status  ; 
mdasC_INFOH  dsinfo  ; 
mdasC.DAT AH  finh,  tailh  ; 
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fp  =  fopenCfin.dat",  "r")  ; 
mdasC_init(argc,  argv,  NULL,  status)  ; 
mdasC_cvt_f p_dh(f p ,  finh,  status)  ; 

mdasC_info_create(MDAS_DATASET,  MDAS.NAME,  "tail.dat",  dsinfo,  status) 
mdasC_ open (NULL,  NULL,  dsinfo,  NULL,  tailh,  status)  ; 

mdasC_close(f inh,  NULL,  status)  ; 
fclose(finh)  ; 

mdasC.close (tailh,  NULL,  status)  ; 

mdasC_f inalize (NULL, status) 

fclose(fp)  ; 

exit(O)  ; 

> 

/*  END  PROGRAM  */ 

4. 7. 3. 8  Executing  Methods 
4.7.3.8.1  MDAS-EXECQ 


MDAS.EXEC (method,  params,  rsrc,  ds_in,  ds_out,  status) 


method:  (IN/OUT) 
params:  (IN/OUT) 
rsrc:  (IN/OUT) 
ds_in:  (IN/OUT) 
ds_out:  (IN/OUT) 
status:  (IN/OUT) 


MDAS_INFOH 

MDAS.INFOH 

MDAS.INFOH 

MDAS.INFOH 

MDAS.INFOH 

MDAS.status 


status  codes 

type 

meaning 

MDAS.SUCCESS 

success 

request  completed 

MDAS_WARN_METHOD 

warning 

method  is  empty  or  NULL 

MDAS_WARN_PARAMS 

warning 

params  is  empty  or  NULL 

MDAS_WARN_RESOURCE 

warning 

rsrc  is  empty  or  NULL 

MDAS.WARN.INPUT 

warning 

ds_in  is  empty  or  NULL 

MDAS_WARN_ OUTPUT 

warning 

ds_out  is  empty  or  NULL 

MDAS.ERR.MEMORY 

error 

unable  to  allocate  memory 

MDAS_ERR_SERVER 

error 

server  not  available 

MDAS.ERR.METHOD 

error 

method  error 

MDAS.EXEC  discussion:  TBD. 
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MDAS  Data  Type 

Fortran  90  Type 

ANSI  C,  C++  Type 

MDAS.table 

MDAS_graph 

derived  TYPE 
derived  TYPE 

void** 

struct 

Table  4.5:  MDAS  Mid-Level  data  types  and  their  counterparts  in  standard  languages. 

4.8  MDAS  Mid-Level  Interface 


This  section  discusses  the  MDAS  Mid-Level  in  detail.  Datatypes  exposed  to  the  user  at 
this  level  are  discussed  in  section  4.8.1.  Function  prototypes  are  presented  in  section  4.8.2. 


4.8.1  Mid-Level  Data  Types 

In  addition  to  the  types  supported  at  the  API  level  (4.7.1),  MDAS  supports  types  for  use  at 
the  Mid-Level  library  interface.  A  list  of  currently  supported  types  is  given  in  table  ??.  The 
implementation  of  these  types  is  language  and  architecture  dependent.  Type  conversions 
between  languages  and  architectures  is  performed  by  Mid-Level  routines  in  the  MDAS 
library. 


4. 8. 1.1  Graph 

TBD. 

The  MDAS_graph  structure  is  the  primary  protocol  for  communications  between  an  MDAS- 
enabled  application  and  an  MDAS  daemon.  It  is  also  used  by  higher  level  libraries  for  direct 
interface  with  the  MDAS  trasparency  and  transaction  engines.  Internally,  an  MDAS_graph 
structure  is  a  directed  graph  whose  nodes  and  vertices  are  defined  by  MDAS.info  structures. 
An  interface  to  MDAS.graph  handles  is  given  in  section  ??. 


4.8.1. 2  Table 


TBD. 

The  MDAS  Library  defines  the  type  MDAS.table  for  direct  import  and  export  of  DBMS 
tables.  The  MDAS_table  type  most  often  appears  as  a  value  with  token  MDAS_SD  in  an 
MDAS.info  structure  and  thus  unseen  by  users.  Input/Output  operations  on  large  tables 
may  be  internally  spooled.  An  interface  to  MDAS.table  handles  is  given  in  section  ??. 


4. 8. 1.3  Handle  Structures 
TBD. 
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MDAS  Handle  Type 

Purpose 

MDAS.GH 

MDAS.TABLH 

handle  to  MDAS_graph  structure 
handle  to  MDAS.table  structure 

Table  4.6:  Additional  MDAS  handles. 

Needs  to  describe  details  of  handle  structures. 

The  MDAS  Mid-Level  Library  defines  handles  for  MDAS.graph  and  MDAS.table  structures, 
along  with  routines  to  manipulate  the  attributes  of  MDAS-defined  handle  types.  This 
section  discusses  handle  attributes  and  structures.  A  list  of  Mid-Level  MDAS.handle  types 
is  given  in  table  4.6. 


4.8.2  Mid-Level  Prototypes 

TBD. 


4. 8. 2.1  Library  Initialization 

MDAS_INITIALIZED()  allows  layered  libraries  to  determine  if  another  library  in  the  applica¬ 
tion  code  has  called  MDAS_INIT()  or  MDAS_FINALIZE() .  It  returns  success  (0)  if  the  library 
is  initialized.  Otherwise,  a  warning  code  is  returned  indicating  whether  the  library  has  (a) 
never  been  initialized  or  (b)  has  been  finalized. 

MDAS.INITTALIZED (status) 

status:  (IN/OUT)  MDAS_status 


4.8. 2. 2  Data  Type  Length  and  Packing 

To  support  the  import,  export,  and  internal  transfer  of  data  among  MDAS-enabled  appli¬ 
cations  and  external  environments,  the  MDAS  Library  provides  an  interface  to  obtain  the 
length  of  data  structures  in  the  system. 

MDAS_DATATYPE_LEN (type ,  len,  status) 
type:  (IN)  MDAS.datatype 

len:  (OUT)  integer 

status:  (IN/OUT)  MDAS_status 

MDAS_DATATYPE_LEN()  returns  the  length  (in  bytes)  of  an  MDAS.datatype  (table  4.5.  sec¬ 
tion  ??)  in  the  current  run-time.  If  type  is  a  handle,  the  handle  length  and  not  the 
length  of  the  underlying  structure  is  returned.  Use  MDAS_HANDLE_PACK_LEN()  to  obtain  the 
contiguous  length  of  an  MDAS.handle. 
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MDAS_HANDLE_PACK_LEN (htype,  handle,  len,  status) 
htype:  (IN)  Name  of  MDAS.handle 

handle :  (IN/OUT)  MDAS.handle 
len:  (OUT)  integer 

status:  (IN/OUT)  MDAS.status 


MDAS_HANDLE_PACK_LEN()  returns  the  length  (in  bytes)  of  a  structure  referenced  by  handle — 
as  if  it  were  packed  into  a  contiguous  stream  of  bytes.  The  routine  may  actually  pack  the 
structure  if  internal  optimizations  deem  it  prudent.  Otherwise,  the  structure  is  left  un¬ 
touched.  The  value  supplied  in  htype  must  (currently)  be  one  of  MDAS_GRAPH_HANDLE, 
MDAS_INFOH,  or  MDAS_TABLE_HANDLE. 


MDAS^HANDLE_PACK (htype,  handle,  buffer,  buflen,  len,  status) 
htype:  (IN)  Name  of  MDAS.handle 

handle :  (IN/OUT)  MDAS.handle 

buffer:  (IN/OUT)  MDAS.handle  (user  defined  buffer) 
buflen:  (IN)  integer 

len:  (OUT)  integer 

status:  (IN/OUT)  MDAS_ status 


MDAS.HANDLE.PACKO  packs  a  structure  referenced  by  handle  into  a  contiguous  stream 
of  bytes  which  is  suitable  for  I/O.  The  buffer  must  be  user-allocated  memory  of  length 
buflen.  The  actual  length  of  the  packed  structure  is  returned  in  len.  This  is  guarenteed 
to  be  the  same  length  as  MDAS_HANDLE_PACK_LEN()  would  return  for  the  same  handle 
reference.  A  packed  MDAS_handle  structure  is  functionally  equivalent  to  its  unpacked  form. 

Note:  subsequent  operations  on  the  content  of  a  packed  MDAS_handle  structure  (e.g., 
section  ??)  may  cause  the  structure  to  be  unpacked.  When  an  MDAS.handle  structure  is 
packed  for  I/O  or  communication,  its  content  should  not  be  examined  or  updated  until  the 
I/O  transaction  is  complete. 


4. 8. 2. 3  Program  Graph  Interface 

One  of  the  prime  MDAS  objectives  is  the  replacement  of  the  Unix  file  paradigm  with  a  high- 
level  data  set  abstraction.  To  do  so  also  requires  the  abstraction  of  programs  to  methods, 
since  programs  are  typically  stored  as  executable  files .  Visual  programming  environments 
have  proven  to  be  an  effective  interface  for  the  design  and  prototyping  of  software  systems. 
The  MDAS  “Program  Graph  Interface”  provides  a  direct  means  for  visual  programming 
GUIs  to  interface  the  MDAS  transparency  and  transaction  engines.  MDAS  Daemons  and 
many  High-Level  MDAS  API  functions  such  as  MDAS_GET(),  MDAS_PUT(),  MDAS_*_PIPE() , 
and  MDAS_*_MPLX()  are  implemented  with  this  Mid- Level  interface. 


MDAS.GRAPH, CREATE (gh ,  status) 

gh:  (IN/OUT)  MDAS_GRAPH_HANDLE 

status:  (IN/OUT)  MDAS_status 
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MDAS_GRAPH_DUP(ghl,  gh2,  status) 

ghl :  (IN/OUT)  MDAS.GRAPH.HANDLE 
gh2 :  (IN/OUT)  MDAS_GRAPH_HANDLE 
status:  (IN/OUT)  MDAS.status 


MDAS_GRAPH_ADD_NODE(inf o ,  gh,  status) 
info:  (IN)  MDAS.INFOH 

gh:  (IN/OUT)  MDAS.GRAPH.HANDLE 

status:  (IN/OUT)  MDAS.status 


MDAS_GRAPH_DEL_NODE(inf o ,  gh,  status) 
info:  (IN)  MDAS.INFOH 

gh:  (IN/OUT)  MDAS_GRAPH_HANDLE 

status:  (IN/OUT)  MDAS.status 

MDAS_GRAPH_CONNECT(infol,  info2,  cinfo,  gh,  status) 
infol:  (IN)  MDAS.INFOH 

inf o2 :  (IN)  MDAS.INFOH 

cinfo:  (IN)  MDAS.INFOH 

gh:  (IN/OUT)  MDAS.GRAPH.HANDLE 

status:  (IN/OUT)  MDAS.status 


MDAS_GRAPH_CUT(infol ,  info2,  gh,  status) 
infol:  (IN)  MDAS.INFOH 

inf o2 :  (IN)  MDAS.INFOH 

gh:  (IN/OUT)  MDAS.GRAPH.HANDLE 

status:  (IN/OUT)  MDAS.status 


MDAS_GRAPH_SELECT(inf o ,  gh,  status) 
info:  (IN)  MDAS.INFOH 

gh:  (IN/OUT)  MDAS.GRAPH.HANDLE 

status:  (IN/OUT)  MDAS.status 

MDAS.GRAPH.CURSOR.SCAN (gh ,  action,  scalar,  status) 
gh:  (IN/OUT)  MDAS.GRAPH.HANDLE 

action:  (IN)  integer 

scalar:  (OUT)  integer 
status:  (IN/OUT)  MDAS.status 

(This  needs  to  be  updated  for  graphs.)  MDAS.GRAPH.CURSOR.SCAN ()  returns  the  cursor 
position,  level,  or  size  values  of  MDAS.graph  structures.  The  result  is  returned  in  scalar. 
The  gh  argument  is  a  handle  to  the  structure  of  interest.  Valid  action  values  are: 
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MDAS_LEVEL_GET  get  the  level  of  the  current  cursor  position 
MDAS_CURSOR_SIZE  get  the  size  of  the  MDAS_graph  structure  at  the  current  level 
MDAS_CURSOR_GET  get  index  of  current  cursor  position  in  current  level 


MDAS_GRAPH_CURSOR(gh, 
gh:  (IN/0.UT) 

action:  (IN) 
index:  (IN) 

status:  (IN/OUT) 


action,  index,  status) 
MDAS.GRAPH.HANDLE 
integer 
integer 
MDAS_status 


MDAS_GRAPH_COPY(gh,  ghcopy,  status) 

gh:  (IN/OUT)  MDAS_GRAPH_HANDLE 

ghcopy:  (OUT)  MDAS.GRAPH.HANDLE 
status:  (IN/OUT)  MDAS.status 

MDAS_GRAPH_EXEC (gh ,  rsrc,  status) 

gh:  (IN/OUT)  MDAS_GRAPH_HANDLE 

rsrc:  (IN)  MDAS.INFOH 

status:  (IN/OUT)  MDAS_status 

MDAS_GRAPH_FREE(gh,  status) 

gh:  (IN/OUT)  MDAS_GRAPH_HANDLE 

status:  (IN/OUT)  MDAS_status 


4. 8. 2. 4  Direct  Query  Interface 


MDAS_SD_QUERY(info,  cond,  extent,  result,  status) 


info:  (IN) 

cond:  (IN) 

extent:  (IN) 
result:  (OUT) 
status:  (IN/OUT) 


MDAS.INFOH 

MDAS.INFOH 

MDAS.INFOH 

MDAS.INFOH 

MDAS.status 


MDAS.SD.QUERY ( )  extends  the  functionality  of  MDAS.INQUIREO  to  user-defined  specific 
data.  The  call  may  fail  if  no  methods  exist  to  perform  the  requested  query  on  the  specified 
data  set.  Where  supported,  MDAS  will  search  the  contents  of  user  data  for  occurences  of 
user  tokens  and  values  specified  in  info.  An  error  is  returned  if  no  such  tokens  are  found. 


MDAS_SQL_EXEC(. .  .) 
...  TBD 


Since  MDAS  targets  interoperation  between  many  protocols,  an  ANSI  SQL  execute  call  is 
also  provided  for  use  with  SQL-enabled  servers  opened  with  MDAS_CONNECT() . 
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4. 8. 2. 5  Table  Interface 


The  MDAS  Library  provides  and  interface  for  the  direct  import  and  export  of  DBMS  tables. 
TBD. 

Input/Output  operations  on  large  tables  may  be  internally  spooled. 
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4.9  MDAS  Metadata 


This  section  provides  details  on  the  type  of  metadata  maintained  by  MDAS.  It  also  describes 
a  few  scenarios  that  show  the  use  of  this  metadata.  MDAS  maintains  metadata  to  support 
the  following  functionality: 


1.  locating  entities 

2.  gaining  access  to  entities,  and 

3.  performing  computations  with  the  entities 

4.9.1  Locating  Entities 

The  metadata  associated  with  the  locator  functionality  provides  for  a  variety  of  ways  for 
locating  entities  in  the  information  space.  In  the  case  of  data  set  elements,  locator  metadata 
may  originate  either  from  portions  of  the  element  itself  (implicit  metadata)  and/or  may 
arise  from  other  parametric  values  (explicit  metadata)  that  aid  in  locating  the  element. 
For  example,  the  contents  of  a  document  form  part  of  implicit  metadata  whereas  its  name 
and  the  semantics  of  the  contents  form  part  of  explicit  metadata.  In  the  case  of  methods, 
resources  and  users,  the  associated  metadata  is  typically  explicit  in  nature.  Entities  that  are 
of  interest  are  identified  by  queries  against  either  the  system  metadata  (attributes  stored 
for  all  entities)  or  entity  metadata  (attributes  that  are  specific  to  that  class  of  entity). 

4.9.2  Accessing  Entities 


The  access  metadata  provides  information  on  how  to  transport  an  entity,  e.g.  data  set, 
from  its  current  location  to  a  location  of  interest.  Data  sets  and  methods  are  example 
of  transportable  entities.  In  the  case  of  non-transportable  entities,  the  access  metadata 
provides  information  on  how  to  communicate  with  the  entity.  Resources  and  users  are  ex¬ 
amples  of  such  entities.  For  transportable  entities,  the  metadata  provides  information  on 
how  to  authenticate  and  connect  to  the  corresponding  data  server,  and  the  method  to  use  to 
perform  and  mediate  the  transfer  operation.  Information  on  the  applicable  levels  of  locking 
are  maintained  to  control  the  amount  of  concurrent  activity.  Metadata  about  constraints 
that  are  imposed  on  the  transfer  operation  can  also  be  maintained.  Transportable  entities 
may  exist  in  replicates,  or  may  be  distributed  over  a  network,  or  possibly  both.  Transport 
methods  may  allow  for  parallel  transport.  Metadata  to  determine  which  replicate  can  be 
cost-effectively  transferred  and  metadata  to  formulate  a  plan  to  perform  parallel  access  of 
data  sets  may  also  be  stored  in  required  cases.  In  the  case  of  non-transportable  entities,  the 
metadata  provides  methods  which  one  can  use  to  communicate  with  the  entity  and  also  the 
parametric  values  that  can  be  used  to  establish  this  communication.  Again,  authentication 
and  security  metadata  may  also  be  maintained  in  certain  cases.  In  the  case  of  resources, 
statistical  and  usage  metadata  is  maintained  to  facilitate  scheduling  and  accounting  appli¬ 
cations. 
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4.9.3  Computing  With  Entities 


For  data  sets,  the  compute-oriented  metadata  provides  information  on  how  to  transform  and 
present  the  data  to  various  processes,  users  and  resources.  A  data  set  may  be  stored  in  one 
form  while  a  computing  process  may  require  the  data  in  another  form.  MDAS  can  provide 
the  transformation  to  the  acceptable  form  by  maintaining  metadata  about  this  procedure. 
In  the  case  of  resources  and  methods,  the  compute-oriented  metadata  provides  information 
about  the  characteristics  of  inputs  and  outputs  (e.g.  ability  to  support  parallel  I/O),  and 
auxiliary  support  structures  needed  for  effective  computation. 

4.9.4  Usage  of  Metadata 

Following  are  examples  of  the  types  of  requests  that  MDAS  can  respond  to  based  on  its 
metadata. 


4.9.4. 1  Locating  Data  Sets 

A  user  is  only  able  to  describe  a  data  set  of  interest,  but  does  not  know  its  location.  For 
example: 

•  Locate  the  data  set  that  was  created  on  10/10/96  by  using  the  Spectral  Gradient 
Transform  on  the  Intel  Paragon  with  wave  data  collected  by  EOS  satellite  at  2200 
hrs. 

•  Locate  the  text  document  created  by  the  OCR  program  based  on  manuscript  page  24 
for  the  patent  on  “Multithreaded  Supercomputers”. 

•  Locate  the  document  provided  by  Intel  about  the  Paragon  and  dealing  with  FIFO 
cache  registers. 


4.9. 4. 2  Locating  Resources 

A  user  needs  resources  which  conform  to  some  user-defined  specification  but  is  not  aware  of 
the  actual  set  of  resources  available  in  the  heterogeneous,  distributed  computing  environ¬ 
ment.  For  example: 


•  Find  a  computing  platform  with  a  100  Teraflops  rating  which  is  connected  to  Suranet 

•  Find  a  computing  platform  which  can  run  the  “Smith- Waterson”  algorithm  and  also 
provide  1  Teraflops  for  a  20-minute  interval  in  the  next  24-hour  period. 

•  Find  the  nearest  available  resource  that  holds  text  and  image  files  for  Patent  number 
“22224444”.  Execute  the  patent  conversion  utility  that  translates  the  files  into  LaTeX 
and  tiff  form. 
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CD  Tables 


AD  Tables 


TD  Tables 


SD  Tables 


Figure  4.3:  MDAS  Metadata  Tables 


4. 9. 4. 3  Locating  Methods 

A  user  needs  to  find  out  if  a  specific  computational  function  (method)  exists  or  can  be 
applied  to  some  data  set(s)  using  specified  resource(s).  For  example: 


•  Find  a  format  conversion  method  to  convert  from  the  netCDF  format  to  the  vis5D 
format. 

•  Is  there  a  method  to  validate  3D  ECOM-si  hydrodynamic  ocean  simulation  output 
with  observational  data  for  the  San  Diego  Bay? 

•  Can  I  run  a  parallel  interpolation  function  on  regular  grids  of  size  greater  than  1024 
x  1024  on  a  CRAY  MPP  platform? 

4.9.5  Metadata  Schema 

The  metadata  described  in  the  previous  sections  is  stored  in  the  MDAS  Metadata  Catalog 
shown  in  Figure  4.3.  The  central  component  of  the  metadata  database  schema  consists  of 
four  main  Catalog  Data  (CD)  metadata  tables,  one  each  for  the  main  elements  of  MDAS. 
viz.  datasets,  methods,  resources  and  users.  The  CD  metadata  tables  are  supported  by 
several  companion  Auxiliary  Data  (AD)  metadata  tables.  The  CD  and  AD  metadata  tables 
form  a  normalized  schema  for  the  metadata  database.  The  definitions  and  descriptions  of 
several  of  the  attribute  values  in  CD  and  AD  metadata  tables  are  contained  in  Token  Data 
(TD)  metadata  tables.  Apart  from  these  three  types  of  metadata  tables,  which  form  the 
system  level  component  of  the  metadata  database,  optional  Specific  Data  (SD)  metadata 
tables  can  be  defined  for  each  user,  dataset,  method,  and  resource  in  the  system.  The 
SD  metadata  tables  make  up  the  application  level  component  of  the  metadata  database. 
Provisions  are  made  to  access  these  tables  in  conjunction  with  the  system  level  metadata. 
All  or  parts  of  these  tables  may  be  replicated  in  more  than  one  metadatabases  for  high 
availability  and  performance.  The  compositions  of  and  interactions  between  the  table  are 
described  below. 

Table  4.7  provides  the  types  of  attributes  used  in  the  metadata  schema.  Table  4.8  provides 
the  attributes  of  all  TD  metadata  tables.  Table  4.9  provides  the  attributes  of  all  CD  meta¬ 
data  tables.  Tables  4.10,  4.11,  4.12  and  4.13  provide  AD  metadata  for  datasets,  methods. 
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resources  and  users  in  MDAS.  The  schema  digram  for  part  of  the  metadata  database  is 
given  in  Figure  4.4. 
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native  type 

MDAS-DATAJD 

MDAS.RSRCJD 

MDAS.METH.ID 

MDAS.USERJD 

MDAS.DATA_TYPE.ID 

MDAS-RSRC-TYPEJD 

MDAS-METH.TYPE.ID 

MDAS.USER.TYPEJD 

MDAS-DATA-NAME 

MDAS-RSRCJN'AME 

MDAS.METH.NAME 

MDAS.U  SER.N  AM  E 

MDAS_DATA.TYPE.NAME 

MDAS.RSRC -TYPE-NAME 

M  DAS.M  ETH.T  YPE.N  AME 

MDAS.USER.TYPE.NAME 

MDAS-USER-ADDRESS 

MDAS-USER.PHONE 

MDAS.USER.EMAIL 

MDAS-USER.DOMAIN 


native  type 

MDAS.FIELD.NAME 

MDAS.FIELD.TYPE 

MDAS.FIELD_TYPE.NAME 

MDAS.PATH.NAME 

MDAS.REP.POLICY.DESC 

MDAS-REP.TYPE.DESC 

MDAS-PARTITION-DESC 

MDAS-TRIG.DESC 

MDAS-TRIG-MODE 

MDAS-TRIG.CONDITION 

MDAS-ACCESS.DESC 

MDAS.PREDJDESC 

MDAS.FUNCTION.DESC 

MDAS.FUNCTTON.NAME 

MDAS.LANG.TYPE 

MDAS.SCHEMAJD 

MDAS.ACCESSJD 

MDAS.TRIGGERJD 

MDAS-AGGREGATIONJD 

MDAS.FUNCTIONJD 

MDAS.LOCATIONJD 

MDAS.LOC.DESC 


native  type 

MDAS.TICKET.DESC 

MDAS-AUTHENTICATION.DESC 

MDAS.LOCK.DESC 

MDAS.MISC_TYPE.ID 

MDAS.LOCKJD 

MDAS.TICKETJD 

MDAS-AUTHENTICATION.ID 

MDAS.MISC.VALUE 

mdas.misc.name 

MDAS.REP.POLICY.ID 

MDAS.REP_TYPE.ID 

MDAS-PARTITION-SCHEME-ID 

MDAS-ACTIONJD 

MDAS.ACTION-DESC 

MDAS.PARAMETER.TYPE 

MDAS.PARAMETER.  VALUE 

MDAS.PARAMETER.NAME 

MDAS-SD.DESC 

MDAS.KEY 

MDAS_SCHEMA.TYPE.NAME 

MDAS.METH.EXEC.TYPE.NAME 

MDAS-METH_EXEC.TYPE.ID 


Table  4.7:  Native  Type  Definitions  (MDAS  Mid-level) 
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table  name 

M  D  A  S  _T  D  _L  O  CK 

MDAS-TDJDOMAIN 

MDAS-TDJDATA-TYPE 

MDAS_TD_METH_TYPE 

MDAS-TD_RSRC_TYPE 

MDAS_TD-USER_TYPE 

MDAS-TD.EXEC-TYPE 

MDAS-TDJLOCATION 


MDAS.TD_RSRC_FUNCTION 

MDAS_TD_DSET_FIELD_TYPE 

MDAS-TD_DSET_SCHEMA 

MDAS_TD_DSET-SCHEMA_DESCRIPTION 

MDAS_TDJ3PECTRAL_SUMMARY 

MDAS-TD.ACTION 

MDAS_TD_TICKET 

MDAS-TD.REPLICATION.TYPE 

MDAS-TD_AUTHENTICATION 


MDAS_TD_VERIFICATION 

MDAS-TD-ENCRYPTION 


MDAS_TD_DECRYPTION 


MDAS-TD.RSRC -ACCESS 
MDAS-TDJMETH-ACCESS 
MDAS-TD-DSET-ACCESS 
MDAS_TD_DSET_REPLICATION_POLICY 

MDAS-TD-DSET-PARTITION-POLICY 

MDAS_TDJDSET_TRIGGER 

MDAS.TD-DSET-AGGREGATION 

MDAS-TD_METH_REPLICATION_POLICY 

MDAS-TD-RSRC -REPLICATION-POLICY 


attributes _ '  _ 

lock_id,  lock-description,  lock-methodJd 
domain  Jd,  domain-description 

mo_data_typeJd,  datatype  .name,  parent-data_type_id 
mo_method_type_id,  method-type-name, 

parent_method_type_id, 

mo_resource_type_id,  resource-type_name, 

parent_resource-type_id 

mo_user_type_id,  user_type-name,  parent_user_type_id 
executable_type_id,  executable_type_name 
location-id,  location-description,  country,  state,  city, 
county,  site,  building,  wing,  floor,  room,  organization,  de¬ 
partment,  division,  subdivision,  project,  domain,  group, 
latitude,  longitude,  timezone,  zipcode,  netprefix,  nettype, 
function-id,  function-description, 

function_compliance_description,  function_name 
field-type,  field.typ e-name,  conformdanguage 
mo_schema_id,  schema_name,  parent-schema 
mojschemaJd  ,  field_enum  ,  field_name  ,  field-type 
spectral-id ,  spectral-description 
action-id,  action-description 
ticket-id,  ticket-description,  ticket-method 
replication_type_id,  description 

authentication-id,  authentication-description,  authentica¬ 
tion-name,  authentication-kind.  authentication_keylength, 
authentication_public_info,  authentication_metod_id 
verification-id,  verification-description,  verification-name, 
verification-kind,  verification-key  length, 

verification-public_info,  verification_metod_id 
encryption-id,  encryption-description, 

encryption-name,  encryption-kind,  encrypt ion_key length, 
encryption_public_info,  encryption_metodid 
decryption-id,  decryption-description, 

decryption-name,  decryption-kind,  decryption_keylength, 
decryption-public Jnfo,  decryption_metod_id 
mo_access-id,  access-constraint,  ticket-id 
mo-access_id,  access-constraint,  access-ticket.  Jd 
mo^access_id,  access-constraint,  access_ticket_id 
replication-policy  Jd,  replication-description, 

replication-policy  .method  Jd 

partition_scheme_id,  partition-description, 

partition_policy_methodid 

mo_triggerJd,  trigger-description,  trigger-methodid,  trig¬ 
ger-mode,  trigger-condition,  destination_dataJd 
mo_aggregation,  aggregation-description, 

aggregation-method 

replication-policy  Jd,  replicat.ion_policy-description,  repli¬ 
cation-policy  .method  Jd 

replication-policy  Jd,  replication_policy_description_id, 
replication_policy_methodJd 


Table  4.8:  Type  Definition  Tables  (MI) AS  Mid-level) 
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MDAS-CD_DATA  mo_dataJd,  mo_data_iiame,  global_data_type_id, 

global-schema  Jd,  verification-key  ,  verification _id, 
is.partitioned 

MDAS_CD_METHOD  mo-tnethodJd, 

mo_method_name,  mo_method_type_id,  verifica- 
tionJcey,  verification-id,  public_key,  public.Jd, 
is.compound 

MDAS_CD_RESOURCE  mo_resource_id, 

mo_resource_name,  mo_resource_type_id,  verifica¬ 
tion-key,  verificationJd,  public_key,  publicJd 

MDAS-CD-USER  mo_user_id,  mo-User_name,  mo_user_address, 

mo_user_phone,  mo_user_phone2,  mo_user_fax, 
mo_user_email,  mo-user_domain,  mo_user_type_id, 
verification _key,  verificationJd,  publicJvey,  pub- 
licJd 

Table  4.9:  Catalog  Data  Tables  (MDAS  Mid-level) 
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table  name 


attributes 


mo_dataid,  mo_data_name,  mo_user_id 


MDAS-AD_DSET_ALIAS 

MDAS-AD-DSETJDOMAIN 

MDAS_AD-DSET_AUTHENTICATION_KEY 

MDAS-AD-DSETJREPLICATION 

MDAS.ADJDSET.LOCK 

MDAS-ADJDSET_ACCESS 

MDAS-AD.DSET-PARTITION 

MDAS_AD_DSET_AGGREGATION 

MDAS_AD_DSET_SUMMARY 

MDAS_AD_DSET_TRIGGER 

MDAS-ADJDSET  .AUDIT 

MDAS_AD-DSET_LINEAGE_DATA 

MDAS-AD_DSET_LINEAGE_METHOD 

MDAS_AD_DSET_LINEAGE_USER 

MDAS_AD_DSET_LINEAGE_PARAMETER 

MDAS-AD.DSET  _LINEAGE_RESOURCE 

MDAS-AD_DSET_SD 

MDAS-AD-DSET-TYPE-SD 


mo_dataid,  domainid 

mo-dataid,  private-key,  privateJockbox_method, 
authentication-id 

mo_data_id,  replication_enum, 

mo_data_name,  mo_data_type_id,  mojschemaid, 
path-name,  mo_resource_id,  replication_type_id, 
replication_policy_id,  replication-timestamp,  size, 
cardinality,  is_deleted,  permanence,  default-flags 
mo_data_id,  replication-enum,  mo_user_id, 
start-time,  end-time,  lockid 

mo_data_id,  replication_enum,  mo-user  _id, 

mo_access_id 

mo_dataJd,  pa.rtition_data_id,  partition_enum, 
partition-scheme 

mo_dataJd,  aggregation-id,  aggregation_data_id 
mo-dataJd,  replication_enum,  actionJd,  spec¬ 
tral-timestamp,  spectral-id,  spectraLvalues 
mo-dataJd,  replication_enum, 

validated_condition,  mo_trigger_id 
mo_data-id,  replication_enum,  mo.user  _id,  ac¬ 
tionJd,  time-stamp 

mo_dataJd,  replication_enum,  parent_dataJd, 
parent_in_data_enum 

mo_dataJd,  replication_enum,  parent_methodJd, 
child-output_enum 

mo_dataJd,  replication_enum,  owner _user_id 
mo_dataJd,  replication_enum,  parameter_enum, 
parameter-value 

mo_dataJd,  replication_enum,  sub_method-enum, 
parent_resource_id 

mo_dataJd,  sd.description,  sd_data_id 
mo_data_type_id,  sd_description,  sd.dataJd 


Table  4.10:  Auxiliary  Data  Tables  for  Datasets  (MDAS  Mid-level) 


table  name 


attributes 


MDAS_AD_METH_ALIAS 

MDAS-AD.METH-DOMAIN 


MDAS_AD_METH_AUTHENTICATION_KEY 

MDAS_AD_METH_DECRYPTION_KEY 

MDAS-ADJVIETH.REPLICATION 

AIDAS_AD.METH.LOCK 

MDAS-AD.METH-ACCESS 

MDAS-AD.METHJSUMMARY 

MDAS_AD_AIETH_AUDIT 

MDAS_AD_METH_LINEAGE_METHOD 

MDAS_AD_METH.LINEAGE.DATA 

MDAS_AD_METH_LINEAGE_USER 

MDAS_AD_METH_LINEAGE_PARAMETER 

MDAS_AD_METH_LINEAGE_RESOURCE 

MDAS_AD_CONVERT.METHOD_ID 

MDAS-AD.CONVERTJVIETHOD.TYPE 

MDAS_AD_METH_APPLICATION_PARAMETER 

MDAS-AD_METH-APPLICATION_OUTPUT 

MDAS_AD_METH_APPLICATIONJNPUT 

MDAS-AD_METH_APPLICATION.REQUIREMENTS 

MDAS_AD_METH_APPLICATION_PREDICTION 

MDAS-AD_METH_COMPOUND_METHOD_MAP 

MDAS_AD-METH.COMPOUND_DSET.MAP 

MDAS_AD_METH_COMPOUND_PARAMETER_MAP 

MDAS_AD_METH_SD 

AIDAS_AD.METH_TYPE.SD 


momiethodJd,  mo_method_name,  mo_user_id 
momiethodJd,  domainJd 

momiethodJd,  private_key, 

privateJockboxmiethod,  authentication-id 
momiethodJd,  private_key, 

privateJockboxmiethod,  decryption-id 
momiethodJd,  replication.enum, 

momiethodmame,  momiethod_type_id, 

executable_type_id,  mo_resource_id,  path_name, 
replication_type_id,  replication-policy  Jd,  replica¬ 
tion-timestamp 

momiethodJd,  replication.enum,  mo.user.id, 
start-time,  end  .time,  lock_id 
momiethodJd,  replication.enum,  mo_user_id, 

mo_access.id 

momiethodJd,  replication.enum,  action  Jd, 
spectral-timestamp,  spectraLid,  spectraLvalue 
replication.enum,  mo_method_id,  mo_user_id,  ac- 
tionJd,  time_stamp 

momiethodJd,  replication.enum, 

parentmiethodJd,  child.output.enum 
momiethodJd,  replication.enum,  parent _data_id, 
p  a  rent  Jn  _d  at  a.enu  m 

momiethodJd,  replication.enum,  owner.user.id 
momiethodJd,  replication.enum, 

parameter.enum,  parameter.value 
momiethodJd,  replication.enum, 

submiethod.enum,  parent,  .resource.id 
momiethodJd,  in_data_type_id.  out_data.type.id 
momiethod_type_id,  in_data_type_id, 

out.data_type.id 

momiethodJd,  parameter.enum,  parameter-type, 
parametermame,  parameter_default_value 
momiethodJd,  out.enum,  out.data.type, 

ou  t  _d  at  am  ame ,  out  .default  .value 
momiethodJd,  in.enum,  in.data.type, 
in.datamame,  in.default .value 
momiethodJd,  miscmame,  misc.type,  misc.value 
momiethodJd,  replication.enum  , 

prediction-met  hod  Jd,  prediction-description 
momiethodJd,  method.enum,  submiethodJd 
momiethodJd, 

producer.method.enum,  producer.out.enum,  con¬ 
sume  r  mie  t  ho  d  _e num ,  con su me r  J n _enu  m 
momiet  ho  d  Jd ,  met  ho  d  .p  ar  am  .enum , 

sub  mie  t  ho  d  _p  ar  am  _e  n  u  m 
momiethodJd,  sd.description,  sd.dataJd 
momiethod.typeJd,  sd.description.  sd.dataJd 


Table  4.11:  Auxiliary  Data  Tables  for  Methods  (AIDAS  Mid-level) 


table  name 


attributes 


MDAS-AD-RSRC  .ALIAS 
MDAS-AD-RSRC  .DOMAIN 
MDAS-AD_RSRC -AUTHENTICATION-KEY 

MDAS-AD-RSRC-DECRYPTION-KEY 

MDAS-AD.RSRC -REPLICATION 

MDAS-AD_RSRC_LOCK 

MDAS-AD-RSRC -ACCESS 

MDAS-AD-RSRC -SUMMARY 

M  D  AS_AD  _RS  RC  _AU  D  IT 

MDAS_AD_RSRC -LINEAGE-RESOURCE 

MDAS_AD-RSRC  _LINEAGE_METHOD 

MDAS-AD-RSRC-LINEAGE-USER 
MDAS-AD_RSRC -LINEAGE-PARAMETER 

MDAS-AD-RSRC-LINE  AGE_DATA 

MDAS-AD-FUNCTION-ON-RESOURCE 

MDAS-AD-RSRC-APPLICATION-PREDICTION 

MDAS_AD_RSRC  _SD 
MDAS_AD_RSRC -TYPE-SD 


mo_resource_id,  mo_resource_name,  mo_user_id 
mo_resource_id,  domainJd 

mo_resource_id,  private-key, 

private_lockbox_method,  authentication  Jd 
mo_resource_id,  private-key, 

privateJockbox_method ,  decryption-id 
mo_resource_id,  replication_enum, 

mo-resource_name,  mo_resource-type_id,  loca¬ 
tion  Jd,  replication_type_id,  replication-timestamp 
mo_resource_id,  replication_enum,  mo_user.id, 
start-time,  end-time,  lock-id 

mo_resource_id,  replication-enum,  mo_user_id, 
mo-access_id 

mo_resource_id,  action_id,  replication-enum,  spec¬ 
tral-timestamp,  spectral-id,  spectral-value 
mo_resource_id,  replication.enum,  mo_user_id,  ac¬ 
tionJd,  timestamp 

mo_resource-id ,  replication-enum , 

sub_method_enum,  parent-resource.id 
mo_resource-id ,  replication_enum , 

parent_method_id 

mo_resource-id,  replica.tion_enum,  owner _user_id 
mo_resource-id,  replication_enum, 

parameter.enum,  parameter  .value 
mo_resource_id,  replication_enum,  parent.dataJd, 
parent  _in_data_enum 

mo_resource-id,  mo_tnethod_id,  function-id 
mo_resource_id,  replication_enum, 

prediction_method_id,  prediction-description 
mo_resource_id,  sd_description,  scLdata_id 
mo_resource_type_id,  sd.description,  sd.dataJd 


Table  4.12:  Auxiliary  Data  Tables  for  Resources  (MDAS  Mid-level) 


table  name 

attributes 

MDAS-AD.USER-ALIAS 

mo_user_id,  mo_user_name 

MDAS-AD.USER.GROUP 

mo_user_id,  group_user-id 

MDAS_AD.USER.DOM  AIN 

mo_user_id,  domainJd 

MDAS_AD.USER_AUTHENTICATION-KEY 

mo-iiser_id,  private-key,  privateJockbox_method, 
authentication-id 

MDAS_AD_USER.DECRYPTION.KEY 

mo_user_id,  private-key,  privateJockbox_method, 
decryption-id 

MDAS_AD.USER.SUMM  ARY 

mo_user_id,  actionJd,  spectral-timestamp,  spec¬ 
tral-id,  spectral-value 

MDAS-AD -USER-AUDIT 

mo_user_id,  actionJd,  time _jst. amp 

MDAS_AD.USER.SD 

mo-user.id,  sd_description,  sd_data.Jd 

MDAS_AD.USER.TYPE.SD 

mo_user_typeJd,  sd.description,  sd_dataJd 

Table  4.13:  Auxiliary  Data  Tables  for  Users  (MDAS  Mid-level) 
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We  start  with  the  CD  table  for  datasets  along  with  two  important  AD  tables. 


M DA  S-CD.DA  TA 
(mo-dataJd 
mo-datajname 
globciLdataJypeJd 
globaLschema  Jd 
verification-key 
verification  Jd 
is-partitioned 

); 


dprimary  key 


dereferences  MDAS-TD-DA TA-TYPE 
dereferences  MDAS-TD-DSETSTR  UCTURE 
%  public  key  for  verification 
dereferences  MDAS-TD.  VERIFICA TION 


MDAS-AD-DSET.REPLICATION 


( mojdata  Jd 

replication-enum 

mo-data-name 

mo-data  JypeJd 

moschemaJd 

path-name 

mo-resourceJd 

replication-type -icl 

re  plication -policy  Jd 

replication-timestamp 

size 

cardinality 
is -dele  ted 


dereferences  M DA S-CD-DA TA 
dcunique  to  each  copy  of  a  dataset 

dereferences  M DA S- TD.DATA-T YPE 

dereferences  MDAS-TD-DSETSTR UCTURE 

dopath  of  file/large  object  or  da  tabase  name  of  table 

dereferences  MDAS.CD.RESO URGE 

dereferences  MDAS-TD-DSET-REPLICA TION.TYPE 

dereferences  MDAS-TD-DSET-REPLICA TION-POLICY 


permanence 

default-flags 

); 

MDAS-AD-DSET-PARTITION 

mo-dataJd 

partition-dataJd 

partition-enum 
partition-scheme  Jd 
); 


%  re  fere  rices  MD  AS. CD. DA  TA 

dereferences  MDAS.CD.DA  TA 

%unique  ids  given  to  each  partition 

%enumeration  of  partition  of  a  dataset 

dereferences  MDA S. TD.DSE T.PA R TITION POLICY 


The  mo.data.id  is  a  catalog-wide  unique  identifier  given  to  each  dataset  registered  in  the 
catalog.  We  allow  two  separate  MDAS  catalog  systems  to  share  the  same  identifier  space: 
but,  we  ensure  uniqueness  across  all  catalogs  by  combining  data  set  identifiers  with  the 
catalog  names.  Hence,  we  do  not  require  a  centralized  identifier-generator  system  to  main¬ 
tain  unique  identity.  The  catalog  name  for  each  MDAS  catalog  is  generated  using  the  ip  or 
network  address  of  the  system  on  which  the  MDAS  resides  and  also  the  creation  timestamp, 
thereby  ensuring  uniqueness  in  the  MDAS  catalog  names  domain.  In  MDAS,  the  identifiers 
for  datasets  are  generated  using  an  incremental  counter  (stored  in  a  table  of  counters).  One 
can  ask  for  the  next  identifier  or  ask  for  a  block  of  n  identifiers. 

Even  though  the  combination  of  dataset  identifiers  and  catalog  names  provide  uniqueness  in 
identification,  it  does  not  solve  the  problem  of  finding  whether  two  identifiers  (residing  in  two 
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different  catalogs)  point  to  the  same  dataset.  That  resolution  can  be  done  by  dereferencing 
the  path. name  and  resolving  the  mo. resource  .ids.  We  consider  that  this  problem  of  dual 
references  is  not  important  enough  to  warrant  a  complicated  method  to  generate  unique 
identifiers  based  on  contents  and/or  location. 

Normally,  deleted  datasets  do  not  relinquish  their  identifiers  and  the  identifiers  are  not 
reused.  But,  provisions  will  be  made  to  provide  a  high  water  mark  (possibly  around  the  90% 
mark  of  the  maximum  possible  identifier  that  can  be  generated)  in  the  identifier  generation 
when  a  garbage  collection  is  performed  to  get  a  list  of  reusable  identifiers.  In  case,  one  hits 
a  second  higher  (98%)  water  mark  (possibly  after  reusing  old  identifiers),  MDAS  should 
start  building  another  catalog  and  redirect  all  insertions  to  the  new  catalog. 

A  registered  dataset  can  either  be  replicated  or  partitioned.  Each  replicated  copy  retains 
the  mo.data.id  given  to  the  dataset  in  the  MDAS_CD_DATA,  whereas  each  partition  of  a 
dataset  are  given  a  unique  mo.data.id.  This  decision  was  made  because  of  the  following 
reasons:  each  partition  of  a  database  can  be  manipulated  separately  independent  of  other 
partitions  and  hence  behave  as  individual  datasets  in  their  own  rights.  On  the  other  hand, 
even  though  each  replication  of  a  dataset  are  accessed  independently  of  other  replicas, 
any  changes  made  to  one  should  be  reflected  in  all  of  them,  i.e.,  each  replica  should  be 
semantically  isomorphic;  hence  they  carry  the  same  identifier. 

Each  replica  is  identified  from  its  siblings  by  the  replication. enum  attribute  as  given  in 
table  MDAS^\-D_DSET-REPLICATION.  The  attribute  mo.data.id  is  a  virtual  identifier, 
where  as  the  combination  ( mo.data.id ,  replication  .enum)  forms  a  real  identifier.  The 
( mo. resource. id ,  path.name)  combination  provides  the  physical  means  of  locating  the 
actual  dataset.  Even  though  each  replica  are  required  to  be  semantically  equivalent,  they 
can  differ  in  their  formats  (syntax).  For  example,  consider  a  latex  file  paper.tex  and 
its  derivatives  paper.dvi  and  paper.ps.  In  MDAS.  the  three  files  are  considered  to  be 
semantically  equivalent  and  are  stored  under  the  same  identifier.  The  mo.data.name  and 
mo.data.type. id  attributes  defined  in  the  MDAS_AD_DSET_REPLICATION  allows  for  dif¬ 
ferent  type  and  name  values.  We  do  not  allow  the  concept  of  partitioning  a  replica. 

The  is-partitioned  attribute  in  the  MDAS_CD_DATA  table  flags  whetehr  the  dataset  is  par¬ 
titioned  or  not.  Unique  identification  of  partitions  is  done  in  the  MDAS  -ADJDSET-PARTITION. 
The  partition. enum  attribute  provides  the  actual  ordering  of  the  partitions  with  respect  to 
the  original  unpartitioned  dataset.  Partitions  provide  convenience  in  more  than  one  way. 

For  very  large  datasets,  finding  space  in  a  single  storage  system  may  not  be  possible  and 
partitioning  provides  a  natural  means  to  overcome  this  problem.  Partitions  can  be  driven 
by  application-level  constraints  and  for  efficiency  reasons.  Assume  a  dataset  that  contains 
nation-wide  data,  where  the  data  is  mostly  used  inside  regions  with  a  few  operations  per¬ 
formed  nation-wide.  Then  partitioning  the  data  region-wise,  and  distributing  them  to  be 
stored  at  regional  centers  may  be  highly  efficient.  Since  the  datasets  have  distinct  identi¬ 
fiers,  updates,  access,  locks  and  other  access  controls  on  one  of  the  partitions  need  not  affect 
other  partitions.  An  operation  over  the  full  dataset  can  still  be  accomplished  seamlessly  by 
performing  it  on  the  (virtual)  parent  dataset  which  will  be  automatically  applied  to  all  the 
partitions. 

Partitioning  the  dataset  is  controlled  by  a  partition. policy. method. id  attribute;  the  table 
MDAS.TD_DSET_PARTITION-POLICY  provides  a  pointer  to  this  method.  This  affords 
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a  flexibility  to  perform  the  partitioning  using  syntactic  or  semantic  criteria  and  is  not 
dependent  on  partitioning  provided  by  the  storage  system.  For  example,  a  large  text,  such 
as  a  patent,  can  be  partitioned  such  that  all  its  images  are  stored  in  one  partition  and  other 
parts  in  another  partition.  One  may  then  view  or  modify  only  the  text  parts,  or  the  image 
parts,  without  accessing  the  other  parts. 

Each  partition  of  a  dataset  can  be  of  different  types  since  they  are  viewed  as  registered 
datasets.  This  mechanism’  allows  one  to  store  each  partition  in  a  convenient  form  or  in 
an  efficient  form  at  the  storage  site.  For  example,  a  large  table  that  is  partitioned  and 
distributed  nation-wide  may  be  stored  in  a  variety  of  database  systems  taking  advantage  of 
what  is  available  locally;  one  partition  may  be  stored  in  a  DB2  system,  where  as  another 
may  reside  in  an  Oracle  database,  and  yet  another  in  an  Illustra  database.  Such  storage 
flexibility  may  allow  local  user  to  access  the  data  in  a  method  familiar  and  convenient  to 
them.  Operations  on  other  partitions  or  on  all  partitions  may  seamlessly  present  the  table 
in  a  familiar  form  by  making  appropriate  changes  based  on  the  global  JataJypeJd  attribute 
of  each  partitioned  dataset.  Note  that,  in  the  case  of  database  tables,  this  functionality  is 
an  enhancement  on  the  ODBC  concept  as  it  applies  to  partitions  of  datasets  which  are 
of  different  types  instead  of  datasets  of  different  types.  The  corresponding  operation  (of 
seamless  integration  of  objects  of  different  types)  for  datasets  of  other  types  (other  than 
database  tables)  are  unique  to  MDAS. 

If  an  inverse  operation  for  a  partition  policy  method  exists  (this  information  is  registered 
in  MDAS_AD_CONVERT -METHOD  JD  table)  then  one  can  use  it  as  a  convenient  way  to 
recreate  back  a  singe  dataset.  The  partition. policy -met  hod  Jd  also  plays  another  important 
role.  In  the  case  of  reads  or  update  access,  the  policy  method  provides  a  way  to  identify 
the  partition  (or  partitions)  on  which  the  operation  need  to  be  performed.  Hence,  the 
policy  method  is  used  not  only  as  a  means  of  partitioning  but  also  as  a  access  redirection 
mechanism.  In  the  current  design  of  the  MDA  system,  one  can  partition  each  dataset  using 
only  one  method.  That  is,  more  than  one  way  of  partitioning  a  dataset  is  not  allowed.  But 
each  partition  can  be  further  partitioned  if  necessary  and  further,  any  partition  can  also  be 
replicated  if  desired. 

The  replication-policy Jd  attribute  in  MDAS_AD_DSET .REPLICATION  table  provides  the 
method  (a  pointer  to  which  is  stored  in  the  MDAS.TD _DSET_REPLICATION_POLICY 
table)  that  is  used  for  updating  purposes.  That  is,  whenever  a  replica  is  changed,  this 
method  should  be  invoked  to  ensure  that  the  updates  are  propagated  if  desired.  The  up¬ 
dating  method  can  be  different  for  each  replica  and  provides  a  rich  semantics  of  replication. 
One  can  perform  an  immediate  replication  or  deferred  replication  depending  upon  which 
copy  is  being  updated.  Moreover,  one  can  control  which  types  of  updates  are  passed  to 
other  replicas  immediately,  and  which  types  of  updates  are  batched  to  be  deferred  for  later 
transmission.  Updates  can  even  be  controlled  from  being  invisible  to  other  replicas  by  hav¬ 
ing  a  null  update  method  thus  providing  a  version  capability.  One  may  also  have  updates 
to  be  propagated  only  on  explicit  commands  by  the  user  or  only  at  system-defined  intervals 
or  events.  The  update  methods  can  perform  the  necessary  checks  before  passing  on  the 
updates  to  its  replicas.  The  user  is  also  notified  of  any  errors  raised  during  the  updates. 

Another  parameter  that  comes  into  the  picture  during  updates  on  the  replicas  is  the 
replication  JypeJd  attribute  of  the  replicas.  We  envisage  that  replication  may  be  done 
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in  many  ways.  One  can  perform  a  master-slave  copy  which  allows  one  to  update  only  the 
master  copy  which  is  then  passed  on  to  the  slave  copies;  one  can  perform  a  peer-to-peer 
copy  where  updates  can  occur  on  any  of  the  copies  and  can  be  passed  onto  others;  one  can 
perform  a  private  copy  where  changes  are  allowed  on  the  private  copy  but  are  not  passed 
along  to  other  copies  and  updates  at  other  places  will  not  be  reflected  in  the  private  copy; 
one  can  have  a  backup  copy  where  no  updates  are  allowed  and  the  copy  is  also  not  visible  to 
the  users  unless  explicitly  requested;  one  can  have  a  version  copy  where  updates  are  allowed 
on  the  new  version  and  the  old  version  will  not  be  updated  though  it  is  available  to  other 
user  groups;  one  can  have  divergent  copies  where  no  action  is  taken  on  updates  and  each 
copy  diverges  from  its  peers,  and  a  synchronizing  update  is  performed  at  a  later  time  to 
reconcile  the  differences,  or  one  can  have  a  transient  copy  which  can  vanish  after  some  time 
and  is  not  shown  to  users  who  query  about  the  copies.  Other  esoteric  updates  can  be  simi¬ 
larly  accommodated  using  the  combination  of  r eplication .policy  Jd  and  replication  JypeJd 
attributes. 

The  mo-data Jype s  of  datasets  form  an  hierarchy  (see  MDAS_TD_DATA_T\  PE  table).  Ac¬ 
tually  types  of  all  entities  registered  by  MDAS  have  this  property.  This  allows  for  inheritance 
of  properties  and  functions  in  the  hierarchy.  We  do  not  provide  explicit  functionalities  and 
properties  for  datasets  (or  other  entities)  as  part  of  the  system-level  metadata;  we  consider 
them  to  be  part  of  specific  data  and  expect  SD  tables  to  be  defined  for  these  purposes. 

The  mo. data  JypeJd  attribute  in  the  MDAS^VD_DSET_REPLICATION  table  also  provides 
an  ability  to  replicate  a  database  in  different  formats.  Updates  on  such  replicates  in  the 
AIDA  system  generalizes  the  concept  of  traditional  updates  in  distributed  systems.  Apart 
from  update  operations  such  as  insertions,  deletions  and  modifications  on  texts,  tables 
or  other  objects  being  mirrored  in  other  copies  of  the  same  type,  here  one  also  needs  to 
contend  with  updates  across  datasets  of  different  types.  An  update  performed  on  a  dataset 
of  particular  type  may  require  regeneration  of  a  new  copy  of  the  replica  using  thealternate 
format. 

Revisiting  the  example  of  the  latex  file  paper.tex  and  its  derivatives  paper. dvi  and  pa¬ 
per. ps,  any  changes  to  paper.tex  can  be  reflected  on  its  dvi  replica  by  running  a  latex 
command  (or  a  make  command  if  other  files  are  also  involved)  on  the  updated  paper.tex 
file.  Further  the  paper.ps  file  may  be  regenerated  from  the  paper. dvi  file  through  a  dvi2ps 
command.  These  two  commands  may  be  packaged  as  a  single  update  method  for  the  two 
files.  In  this  case  a  useful  method  of  replication  is  that  the  latex  file  is  stored  as  a  master 
and  the  other  two  files  are  stored  as  its  slave  replicas.  The  mirrored  updates  to  the  derived 
files  may  be  done  at  a  user  given  explicit  update  command,  or  at  significant  intervals. 

Note  that  with  this  semantics,  the  update  command  is  being  used  to  provide  a  form  of 
method  transparency ,  wherein  the  commands  to  perform  latex  and  the  dvi2ps  tasks  are 
hidden  from  the  user  as  an  update  method.  Similar  transparencies  can  be  accomplished 
for  compilation  and  linking,  for  generating  up-to-date  statistics,  for  real-time  aggregation 
or  deriving  operations,  for  real-time  dataset  displays  under  update  and  even  for  printing  a 
dataset  (where  a  particular  replica  is  considered  to  be  stored  in  the  printer  in  a  printable 
format!!). 

One  can  provide  real-time  visualization  by  registering  a  transient  replica  of  the  dataset  as 
being  “stored"  on  the  screen  through  an  interactive  viewer.  The  update  method  issues  a 
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redraw  command  to  the  viewer.  Note  that  in  this  case,  the  screen  is  viewed  as  a  resource  that 
can  be  used  as  a  write-only  transient  store.  The  is.deleted  attribute  can  be  used  to  control 
the  transience  of  the  replica.  For  example,  consider  that  the  user  is  viewing  the  paper.tex 
file  using  an  interactive  viewer  on  its  paper.ps  replica,  and  has  registered  this  “view”  as 
a  transient  replica.  Then,  any  updates  to  paper.tex  gets  reflected  on  its  paper. dvi  and 
paper.ps  replica  file  and  further  on  the  screen  if  proper  reopen  commands  are  placed  in 
its  update  method.  Similarly,  in  this  seamless  semantics,  the  notion  of  a  ‘tele-conferencing’ 
or  ‘designing-by-group’,  and  ‘tele-operating’  reduce  to  that  of  update  performance. 

The  replication  jpolicy  Jd  and  replication  JypeJd  attributes  also  provide  information  about 
the  consistency  and  currency  of  a  replica  with  respect  to  its  peers.  Hence,  one  can  access 
a  copy  knowing  whether  it  contains  stale  data.  One  is  given  a  choice  of  accessing  datasets 
based  on  allowed  levels  of  staleness  (ascertained  by  knowing  the  replication  policy  of  the 
replicas)  and  use  this  criteria  to  access  a  stale  replica  that  may  be  cheaper  to  access  (possibly 
it  resides  on  a  local  file  store)  than  to  access  another  replica  that  is  current  but  needs  a 
costly  access  operation. 

The  replication  paradigm  defined  in  MDAS  also  helps  in  providing  a  a  different  form  of 
format  transparency.  Again  using  the  ‘paper’  example,  one  can  issue  an  edit  command  on 
the  paper  dataset  and  the  system  will  use  the  paper.tex  file  as  the  target  file.  If  a  print 
command  is  used  on  the  same  paper  dataset,  the  paper.ps  file  will  be  used  to  spool  to  a 
(Postscript)  printer. 

Next  we  discuss  the  role  of  the  schema  attribute  in  MDAS-AD  JDSET-REPLICATION  and 
M D AS _C D _D ATA  tables.  Tables  MDAS-AD J)SET_STRUCTURE_DESCRIPTION  and 
MDAS-TD_DSET_STRUCTURE  describes  the  schema  of  the  dataset.  For  example,  in  a 
database  table  it  will  provide  the  database  schema  for  the  table  and  for  a  text  file,  it  may 
provide  the  sectional  organizations.  One  can  use  the  schema  description  to  select  or  read 
portions  of  interest  from  the  dataset  control  mechanisms. 

We  allow  the  schema  attribute  at  the  MDAS.C'DJDATA  level  in  order  to  provide  a  place 
to  hold  a  schema  independent  of  the  individual  copy  format.  For  example,  for  a  table 
replicated  in  a  variety  of  database  systems,  the  global  schema  jd  can  be  used  to  provide  a 
generic  schema.  We  also  allow  hierarchies  in  the  schema  structure.  Not  only  can  this  be 
used  as  an  inheritance  mechanism  for  properties  of  schema  attributes,  but  it  can  also  be 
used  to  record  schema  evolution. 

We  discuss  the  verification  attributes  when  we  discuss  MDAS_CD_METHOD. 

In  MDAS  REPLICATION  AD  tables  are  also  defined  for  methods  and  resources.  Since  a 
method  can  be  replicated  (possibly  compiled  for  different  platforms)  such  a  table  is  neces- 
sary.  The  reason  for  having  a  REPLICATION  AD  table  for  resources  is  to  provide  a  kind 
of  resource  transparency.  In  an  organization,  one  may  view  all  printers  as  common  resource 
and  a  print  command  can  choose  any  one  of  the  available  ones;  these  printers  are  viewed  to 
be  functionally  (semantically)  equivalent.  Of  course,  the  notion  of  updates  does  not  exist 
for  resources  and  the  replication  policy  is  used  to  note  how  to  replicate  a.  given  resource 
(eg.  make  and  configuration  files  needed  for  setting  up  an  identical  resource). 

The  PARTITION  AD  table  is  particular  to  datasets  and  has  no  equivalent  counterpart  for 
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methods,  resources  and  users. 

The  following  AD  tables  along  with  relevant  TD  tables  capture  access  control  metadata  for 
datasets  in  MDAS. 


MDA  S-A  D.DSE  T.A  CCESS 


(mo.data.id 
replication .enum 
mo-user  Jd 
mo.accessJd. 


%together  form  reference  to 
%  MDAS -A  D-DSET -REPLICA  TION 
%references  MDAS-CD-USER 
do  refe  rences  M  DA  S.  T  D-D  SET -A  CC ESS 


); 

MDA  S-A  D-DSE  T.L  OCR 

(mo. data  Jd  %together  form  reference  to 

replication.enum  %  M  DA  .ST 4  D-D  SET -REP  LICA  TION 

mo-user  Jd  dereferences  MDAS.CD.USER 

start-time 


end.time 

lock-id  dereferences  MDAS.TD.LOCK 

); 

M DA  S-A  D.DSE  T.D  OM A  IN 

(mo-dataJd  dereferences  MDAS.CD.DATA 

domainJd  dereferences  MDAS.TD.DOMAIN 

); 


The  mo-access  Jd  attribute  can  be  used  to  find  the  types  of  access  (as  described  in  the 
MDAS_TD_DSET_ACCESS  table)  that  are  allowed  on  the  dataset  and  can  also  be  used 
to  obtain  an  appropriate  ticket  once  the  appropriate  access  has  been  validated.  The 
MDAS_4D_DSET_ACCESS  table  uses  the  user’s  identification  to  check  for  access  permis¬ 
sions  to  a  dataset.  The  types  of  access  that  are  permitted  are  defined  by  the  access  .constraint. 
attribute  in  the  MDAS.TD _DSET_ACCESS  table.  Examples  of  access  include  read,  write, 
append,  delete,  execute,  replicate,  partition,  control,  etc.  If  a  type  of  access  to  a  dataset  for 
a  particular  user  is  permitted  a  corresponding  entry  will  be  available  in  the  AD  table  Then, 
the  ticket  Jd  attribute  (in  the  TD  table)  can  be  used  to  obtain  a  ticket  that  will  provide  a 
user  transparent  access  to  the  dataset  in  a  particular  domain.  Such  a  ticket  can  be  used  to 
validate  the  access  to  a  dataset  if  a  remote  storage  system  that  stores  the  dataset  requires 
user  authentication. 


The  lock  attribute  is  primarily  for  transaction  management  purposes.  Its  utility  is  similar 
to  that  found  in  database  management  systems.  Apart  from  the  normal  kinds  of  locks 
(eg.  read  lock,  exclusive  read  lock,  write  lock,  etc.,),  the  lock  attribute  can  also  be  used 
as  a  reservation  mechanism.  Assume  that  one  of  the  users  is  planning  to  edit  a  copy  of 
the  paper. tex  file  and  wishes  that  it  not  be  used  by  others  during  that  period.  The  user 
can  lock  the  replica  of  interest  for  sufficient  amount  of  time.  This  facility  will  be  useful 
when  one  needs  to  lock  all  copies  of  a  dataset  for  some  extended  time  for  some  purpose. 
Then,  other  users  are  given  an  indication  about  when  to  expect  the  dataset  to  be  back  on 
line.  The  lock  facility  can  also  be  used  for  advance  reservation.  One  can  anticipate  one  s 
needs  and  reserve  the  dataset  for  a  block  of  time  in  the  future.  At  the  dataset  level  this 
functionality  will  provide  a  means  to  facilitate  group-design  with  individual  time  slots.  In 
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the  case  of  resources  and  methods,  the  reservation  via  locking  mechanism  gives  a  facility  to 
ensure  future  availability  of  resources  for  quality  of  service  purposes,  and  can  be  used  by 
schedulers  effectively. 

The  concept  of  a  domain  is  used  as  an  additional  level  of  security,  apart  from  the  ones  given 
by  access,  and  authentication  and  encryption  mechanisms.  A  domain  is  considered  to  be 
a  secure  area  in  which  one  can  expect  protection  with  respect  to  authenticated  datasets 
and  secure  communications.  We  consider  that  each  dataset  is  associated  with  one  or  more 
domains  (whose  descriptions  are  given  in  the  MDAS-TD  JDOMAIN  table)  authorized  in  the 
MDAS_AD_DSET_DOMAIN  table.  One,  can  move  a  dataset,  or  parts  or  copies  of  it,  only 
within  those  domains. 

In  MDAS,  ACCESS  and  LOCK  AD  tables  are  also  provided  for  methods  and  resources, 
and  DOMAIN  AD  table  is  provided  for  users,  methods  and  resources. 

Next  we  look  at  two  AD  tables  useful  for  statistical  and  accounting  purposes. 


); 

MDAS-AD-DSET-A  UDIT 
(mo -data  Ad 
replication-enum 
mo-itserJd 
mo -action  Jd 
timestamp 


dotoqether  form  reference  to 
%MD  AS -AD -DSET -REPLICA  TION 
dereferences  AIDAS-CD-USER 
dereferences  MDAS. TD-A CTION 


MDAS-AD-DSETSUMMARY 


(mo-dataJd 
replication-e  n  um 
mo-actionJd 
spectra  Lti  m  es  tamp 
spectral-id 
spectral-value 
); 


%  toy  ether  form  reference  to 

%M DA  S-A  D-DSE  T -REPLICA  TION 

dereferences  M DA S- TD-A C TION 

dereferences  MDAS-  T D-SPECTRA  L  JSUMMA  R  Y 


The  MDAS_AD_DSET_AUDIT  table  is  used  to  log  in  an  audit  trail  about  the  usage  of  the 
datasets.  Every  operation  performed  on  every  registered  dataset  is  logged  in  here  and  can 
be  used  to  charge  users  for  accessing  datasets  and  also  for  finding  the  usage  statistics  of 
each  replica  of  the  dataset.  This  information  is  used  to  update  the  permanence  attribute 
in  the  MDAS_AD_DSET_REPLICATION  table.  If  a  replica  falls  below  a  certain  level  of 
permanence,  it  may  be  purged  from  the  system  or  at  least  moved  to  an  archival  storage. 

The  M D A S _A D _D S E T S U M M A RY  table  is  used  to  store  spectral  information  that  is  gleaned 
from  the  audit  trail.  That  is,  for  each  dataset  replica  and  each  operation,  one  finds  the  num¬ 
ber  times  the  action  has  been  performed  in  a  particular  time  period  (say  past  minute,  past 
hour,  every  Wednesday  in  the  last  year,  etc)  and  are  stored  with  the  appropriate  spectral id. 
Spectral  information  definitions  are  provided  in  the  MDAS_TD_SPECTRAL_SUMMARY 
table.  The  summary  information  can  be  used  for  predicting  usage  statistics  for  datasets. 

The  next  two  AD  tables  provide  metadata  for  operations  that  are  borrowed  from  database 
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systems  but  are  applied  to  any  dataset  in  MDAS. 

AID  AS -A  D.DSET.A  GGREGA  TION 

(mo-data Jd  %references  AIDAS-CD-DATA 

%  parent  data  set  on  which  aggregation  is  being  performed 
aggregationAd  %references  MDAS-TD-DSET-AGGREGATION 

aggregation.data.id  ■  %references  MDAS.CD.DATA 

%  resultant  dataset  holding  the  aggregation. 

); 

AIDAS  .A  D.DSET.  TRIGGER 

(mo.dataJd  %together  form  reference  to 

replication.enum  %AIDAS-AD-DSET-R  EPL I CA  TION 

validated-condition 

moJriggerJd  %references  AIDAS.TD.DSET.TRIGGER 

); 

MDAS.  TD-DSE  T-  TRIGGER 
( moJriggerJd 
trigger-description 

trigger-method  dereferences  MDAS -CD -MET  ROD 

trigger-mode 
t  rigge  r.con  dition 
destinatiou-data-id 

); 


Aggregation  in  DBMS  is  an  operation  that  is  performed  on  tables  to  obtain  summary 
information  of  interest.  For  example,  one  may  want  to  find  the  regional  sales  totals  of  a 
nation-wide  department  store  using  the  receipts  table.  In  the  context  of  other  datasets 
any  derived  dataset  can  be  seen  as  a  result  of  an  ‘aggregation’  operation.  In  this  sense, 
for  each  dataset,  the  MDAS_AD_DSET AGGREGATION  table  provides  pointers  to  all 
derived  datasets.  This  can  be  seen  as  an  inverse  of  the  lineage  data  provided  by  other 
tables  (discussed  later).  Even  though  every  dataset  has  a  lineage,  the  aggregation  table 
may  contain  only  pointers  to  a  few  important  derived  datasets.  Hence,  the  information 
stored  in  this  table  will  be  helpful  if  a  user  wants  to  find  a  particular  aggregate  of  a  dataset; 
if  the  aggregation  is  not  available,  one  may  need  to  recompute  it. 

Triggers  in  DBMS  are  used  for  enforcing  general  forms  of  integrity  such  as  business  rules 
(eg.,  no  salary  can  be  increased  by  more  than  10%)  and  for  performing  actions  (possibly  out¬ 
side  the  database)  on  insert  delete  or  update  operations.  The  MDAS_AD_DSET_TRIGGER 
table  provides  metadata  to  achieve  similar  capabilities  for  all  types  of  datasets  that  are  regis¬ 
tered  with  the  system.  The  MDAS.TD-DSET .TRIGGER  table  provides  the  trigger-condition 
for  the  trigger,  the  method  that  needs  to  be  performed  if  the  condition  is  true  and  the  time 
at  which  it  is  performed  using  the  trigger-mode  attribute.  The  trigger-mode  may  be  used 
to  defer  the  action,  perform  it  immediately  or  to  spawn  a  new  transaction  to  be  done  inde¬ 
pendent  of  the  triggering  transaction.  It  may  also  be  used  to  suggest  whether  the  trigger 
is  a  one-time  only  trigger  or  a  continuous  trigger.  The  mode  attribute  can  also  be  used 
to  turn  on  or  turn  off  the  trigger.  The  validated  -condition  can  be  used  to  cache  parts  of 
conditions  that  have  already  been  validated  by  previous  trigger  actions.  With  this  facility, 
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one  can  perform  a  trigger  which  has  a  validation  condition  that  requires  information  from 
earlier  states  of  the  dataset. 

The  AGGREGATION  and  TRIGGER  tables  are  not  available  for  other  types  of  entities  in 
MDAS. 

Next  we  see  the  metadata  support  offered  by  MDAS  for  finding  the  lineage  of  a  dataset. 
By  lineage  we  mean  the  information  about  datasets,  resources,  users  and  methods  that 
were  involved  in  creating  the  database.  Lineage  information  does  not  apply  to  updates  to 
datasets. 


M DA  S-A  D-DSE  T. LINE  A  GEJ)A  TA 


( mo -data  Ad 
replication-enum 
parent-dataJd 
pa  re  n  tJ  n  Jtata-e  n  it  m 


%together  form  reference  to 
% M DA  S-A  D.DSE  T.R  EPL ICA  TION 
dereferences  MDAS.CD.DA  TA 
); 

MDAS-AD-DSET.LINEAGE-METHOD 

(mo-dataJd  %together  form  reference  to 

replica  tionje  n  u  m  %  MDAS -A  D-DSETJtEPLICA  TION 

pa  re  n  Dm  e  th  od _  id  %  re fe  re  nee  s  M  DA  S-  CDML ETHOD 

ch  iULou  tp  u  t-  e  n  u  m 

); 

MDAS -A  DMSETMINEA  GE.  USER 

(mo.dataJd  %together  form  reference  to 

replication.enum  %MDASMD.DSET_REPLICA  TION 

owner.userJd  dereferences  MDAS -CD  ^  USER 

); 

MDAS -A  Ij-DSET-LINEA  GEJW  RAMETER 


(mo-dataJd  %tog ether  form  reference  to 

replication-enum  %MDAS-A  D-DSET.REPL  ICA  TION 

parameter-enum 
parameter-value 
); 

MDA  S-\  D-DSET-L  LYE  A  GE.RESO  URGE 

( mo-dataJd ,  %together  form  reference  to 

replication-enum  %MDAS-A  D.DSE  T.R  EPL  ICA  TION 

sub-methocLen  u  m 

parent  .re  source -id  preferences  MDAS-CD-RESO  URC'E 

); 


As  explained  later,  we  consider  that  each  method  (including  compound  methods)  has 
an  enumerated  list  of  input  datasets,  an  enumerated  list  of  parameters  which  when  ap¬ 
plied  to  the  method,  produces  an  enumerated  list  of  output  datasets.  Each  sub-method 
of  a  compound  method  may  be  performed  on  a  different  resource  and  the  method  itself 
may  be  initiated  by  more  than  one  user.  In  providing  metadata  about  the  lineage  of  a 
dataset,  we  consider  it  to  be  an  output  dataset  emitted  by  a  method,  and  capture  all 
relevant  data  that  went  into  its  creation.  The  MDAS_4D_DSET_LINEAGE_DATA  table 
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captures  the  parent  datasets  (and  their  position  in  the  enumerated  list  of  input  datasets) 
that  created  the  dataset  of  interest  given  by  mo-data Jd,  replicatioruznum.  The  method 
that  created  the  dataset  is  captured  in  the  table  MDAS_AD_DSETXINEAGE_METHOD 
along  with  the  information  about  the  position  of  the  created  dataset  in  the  output  list  of 
datasets.  The  MDAS_4D_DSET_LINEAGE_USER  table  captures  the  user  information  and 
the  MDAS_AD_DSET_LINEAGE_PARAMETER  table  records  the  information  about  pa¬ 
rameter  values  used  in  the  creation.  Finally,  the  MDAS_AD_DSET_LINEAGE-RESOURCE 
table  provides  information  about  the  various  resources  used  at  each  step  in  the  method  in¬ 
vocation. 

The  MDAS-AD_DSET_ALIAS  table  given  below  is  a  facility  for  each  user  (or  group)  to 
give  an  alias  name  for  any  dataset,  apart  from  the  one  provided  in  the  MDAS_CD_DATA 
table. 

MDAS-A  D.DSET.ALIA  S 

(mo. data  Jd  Preferences  MDAS-CD.DATA 

mo.data.name 

mo -user Jd  %references  MDAS-CD.USER 

); 

The  following  tables  provide  the  necessary  mapping  for  using  SD  metadata  tables  in  the 
MDAS  framework. 

AIDAS-A  D-DSETSD 

(mo-dataJd  preferences  MDAS-CD.DATA 

sd-description 

sd-dataJd  Preferences  MDAS.CD-DATA 

h 

MDA  S-A  D-D  SET-  T  YPESD 

( mo-data Jype  preferences  MDAS-TD-DATA-TYPE 

sd-description 

sd-datci- id  % refe  re n ces  M DA S- CD -DA  TA 

); 

SD  meta  data  tables  are  defined  outside  the  core  metadata  tables  of  MDAS  and  are  useful 
in  storing  application-specific  metadata.  The  MDAS  system  will  be  able  to  provide  rudi¬ 
mentary  metadata  for  access  and  computation  without  the  aid  of  SD  tables.  The  SD  tables 
are  useful  in  describing  additional  properties  of  datasets,  methods,  resources  and  users.  For 
example,  the  search  indices  provided  by  systems  such  as  Open  Text  for  documents  and 
patents  can  be  useful  SD  tables  that  may  allow  users  to  access  the  documents  through 
keywords.  Properties  of  computing  platforms  such  as  the  speed,  number  of  processors,  size 
of  memory,  etc.,  can  be  useful  SD  metadata,  that  can  be  used  by  a  scheduler  to  find  optimal 
platforms  for  processes. 

The  M D AS _4D _D S ET_S D  table  provides  entries  about  SD  tables  that  are  relevant  to  par¬ 
ticular  datasets,  and  the  MDAS_4D_DSET_TYPE_SD  provides  the  same  information  for 
datasets  of  common  types  (eg.  all  patent  type  datasets  may  share  one  or  more  index  SD 
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tables).  The  description  attribute  provides  keywords  or  definitions  about  the  contents  of 
the  SD  table.  A  query  to  MDAS  can  use  the  description  value  to  find  appropriate  SD  tables 
for  a  given  type  of  dataset  (or  particular  dataset)  and  search  in  it  for  relevant  information. 
For  example,  the  following  SD  table  (also  registered  in  MDAS)  provides  keyword-to-patent 
dataset  mapping  that  can  aid  in  finding  relevant  datasets  of  interest. 

SD-024 

(keyword  %  word  that  occurs  in 

mo-dataJd  %a  (patent)  dataset  registered  in  MDAS 

); 


The  SD_024  table  can  be  made  visible  to  the  user  through  the  MDA  system  by  having  an 
entry  such  as  ('patent'/ key  index* ,  #uLfor.SDJ)24)  in  the  M  D  A  S  _AD  _D  S  ET  _T  YP  E_S  D 
table.  MDAS  will  provide  facilities  to  search  in  such  SD  metadata  tables. 

Next  we  discuss  the  schema  of  metadata  tables  for  methods.  We  do  not  discuss  the  AD  and 
TD  tables  that  have  similar  functionalities  with  respect  to  the  dataset  metadata  tables. 


M DA  5_  CD. ME  TH  OD 
(mo.methodJd 
mo -m  e  th  od _  n  a  m  e 
mo  ^method  .type  Ad 
verification-key 
verification  Ad 
public-key 
public  Ad 
is-compound 
); 


%  public  key  for  verification 
%  references  MDAS.  TD.  VERIFICA  TION 
%  public  key  for  encryption 
preferences  MDAS.TD.ENCR YPTION 


The  MDAS_CD_METHOD  table  is  similar  to  the  CD  table  for  datasets,  except  that  it 
contains  an  is-compound  attribute  (instead  of  an  is. partitioned  attribute)  which  can  be 
used  to  register  compound  methods.  In  MDAS  each  compound  method  is  considered  as  a 
single  method  with  an  enumerated  list  of  input  datasets,  an  enumerated  list  of  parameters 
and  an  enumerated  list  of  output  datasets.  The  metadata  about  these  enumerated  lists 
are  stored  in  corresponding  APPLICATION  AD  tables  discussed  next.  The  mapping  of 
the  compound  method  to  its  constituent  sub-methods  and  the  mapping  of  the  inputs  and 
outputs  between  the  two  and  the  interaction  between  the  sub-methods  are  captured  in  the 
COMPOUND  AD  tables. 

In  MDAS  we  provide  two  types  of  metadata  for  aiding  in  implementing  authentication 
and  encryption  mechanisms.  We  follow  the  mechanisms  outlined  in  [?]  when  defining 
the  metadata.  We  consider  that  a  dataset,  user,  resource  or  method  may  use  private 
signatures  to  authenticate  their  validity  using  privately  held  authentication  keys  and  the 
receiver  of  information  from  these  sources  will  use  publicly  available  verification  keys  to 
check  the  validity  of  their  communications.  The  above  mechanism  helps  in  ensuring  that 
the  receipients  in  the  communication  can  be  convinced  about  the  originator's  validity.  The 
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verification-key  in  MDAS.CD  JVIETHOD  (and  in  other  CD  tables)  are  used  for  verifying  a 
dataset  or  message  for  its  authenticity. 

The  verification-id  provides  a  handle  to  the  verification  method  that  needs  to  be  used  in  the 
checking  process.  The  MDAS-TD -VERIFICATION  table  that  provides  the  method  and  its 
parameters  is  given  below.  A  similar  table  called  MDAS_TD_AUTHENTICATION  helps  in 
applying  the  authenticating  signature  to  a  dataset  or  message  before  communicating  them. 


AIDAS-  TD-  VERIFICA  TION 


(verification-id 
verification-description 
verification-name 
ve  rificat  ion -kin  d 
verification-key  length 
verification_public-info 
verification-method-id  % 


%  description 

%  verification  scheme  (eg.  DSS,RSA,MD5,SHA,etc .) 
%  kind  of  signature  (eg.  symmetric ,  public ) 

%  other  info  such  as  modulo,  etc 
references  MDAS-CD-METHOD 


); 


To  ensure  secrecy,  a  dataset,  user,  resource  or  method  may  use  the  publicly  available  encryp¬ 
tion  keys  of  the  recievers  to  encypher  the  dataset  or  messages  that  are  being  communicated 
to  the  receiver.  The  receiver  (a  user,  resource  or  method)  in  turn  will  use  its  own  privately 
held  decryption  key  to  decypher  the  message.  This  mechanism  helps  in  ensuring  secure 
communications  between  domains  possibly  separated  by  insecure  communication  channels. 
The  encryption-key  in  MDAS_CD_METHOD  are  used  for  encrypting  a  dataset.  The  encrp- 
tion  key  is  available  for  other  CD  tables  except  that  for  datasets.  Datasets  are  not  designed 
to  receive  any  information  and  hence  do  not  require  any  encryption  mechanism. 

The  encryption-id  provides  a  handle  to  the  encryption  method  that  needs  to  be  used  in 
the  cypher  process.  The  MDAS_TD_ENCRYPTION  table  that  provides  the  method  and 
its  parameters  is  given  below.  A  similar  table  called  MDAS-TD JDECR\  PTION  helps  in 
applying  the  decyphering  a  dataset  or  message  after  receiving  them. 


MDAS-TD-ENCR  YPTION 

(encryption-id 
encryption-description 
encryption-name 
encryption-kind 
encryption-keylength 

encryption-public -info  %  other  info  such  as  modulo,  etc 

encryption-method-id  %  references  MDAS-CD-METHOD 

): 


%  description 
%  encryption  scheme 

%  kind  of  encryption  (eg.  symmetric ,  public) 


Apart  from  the  publicly  available  signature  verification  keys  and  encryption  keys,  their 
counterparts  of  private  authentication  and  decryptio  keys  are  stored  in  (or  at  leaset  via) 
MDAS  in  corresponding  AD  tables.  Below,  we  show  the  AD  tables  for  methods.  Similar 
tables  are  available  for  resources,  users  and  datasets. 
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MDA  S-A  D.METH.A  UT HEN  TIC A  TIONJCE  Y 

(mo-methodJd  %  referencs  MDAS.CD.METHOD 

private-key  %  public  key  is  stored  in  a  secure  DBMS  or 

private Jockbox.method  do  a  method  is  used  to  access 

do  a  private  key  held  in  a  lock  box 
do  referencs  M DA S-CD -METHOD 

authentication-id  dereferences  MDAS-TD-A  UTHENTICATION 

); 

MDAS-AD-METH-DEC'RYPTION-KEY 

(mo-method-id  do  referencs  MD ^45 -CD -METHOD 

private-key 

privateJockboxjmethod  %  referencs  M DA S-C'D-M E T HOD 

decryption-id  dereferences  MDAS-TD-DEC'RYPTION 

); 

We  assume  that  either  a  private  key  is  held  in  a  secure  DBMS  or  a  method  is  available  for 
getting  hold  of  a  key  from  a  software  lock  box.  The  authentication  Jd  (sim.  decryption-id) 
provide  a  handle  to  the  methods  that  is  used  to  apply  the  authentication  key  (or  decryption 
key)  to  a  message  or  dataset. 


MDAS^DAIETHJlPPLICATIONJ>ARAMETER 

(mojmethodJd  preferences  MDA S. CD. ME THOD 

parameter. enum 
pa  ra  mete  rJype 
parameter. name 
pa  ra  mete  r_  clef  a  u  l  L  value 
); 

MDA  5_4  D-ME  TH.A  P  PLICA  TION.O  UTP  UT 

(mo-method-id  dereferences  MDAS-CD-METHOD 

out.enum 

out. dat  ({.type  Jd 

out.data.name 

o  u  t. clef  a  u  It.  vet  lue 

h 

MDAS.A  D-METH-APPLICA  TIONJNPUT 

(mo.methocl.icl  Preferences  MDAS.CD.METHOD 

in.enum 

in.data.type.id 

in.data.name 

in.defaiilt-vahie 

); 

MDA  S-A  D-ME  THA  PPLICA  TIONMEQ  U1  REM  ENTS 

(mo-method-id  dereferences  MDAS-C'D-METHOD 

misc-name 
miscJype 
misc-value 
); 
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ML)  AS -A  D.ME  THM  P PLICA  TIONTPREDICTION 

(mo.method.id  %references  MDAS-CD.METHOD 

replication.enum 

prediction ^meth od.id  dereferences  MDAS.CD.METHOD 

prediction-description 

); 

The  APPLICATION  table  captures  metadata  about  how  to  use  the  methods  registered  with 
MDAS.  The  MDAS_AD_METH_APPLICATION_PARAMETER  table  contains  information 
about  all  the  command-line  parameters  that  can  be  given  when  invoking  the  method.  The 
parameters  are  enumerated  in  a  list  and  this  enumeration  is  used  when  using  the  method 
as  a  sub-method  in  a  compound  method  or  to  record  lineage  information  as  discussed  for 
datasets.  The  name  and  type  of  the  parameter  is  included  along  with  a  default  value  that 
can  be  used  in  case  the  user  fails  to  supply  a  value. 

The  MDAS_AD_METH_APPLICATION-OUTPUT  table  provides  information  about  the 
output  datasets  created  by  the  method.  The  type  of  dataset  is  also  noted  along  with  the 
name  that  is  used  to  describe  the  output  dataset.  A  default  value  for  naming  the  output 
dataset  is  also  provided  in  case  the  user  fails  to  give  a  name  for  storing  the  output.  The 
MDAS-AD  JVIETH_APPLICATION_INPUT  table  provides  similar  information  about  input 
datasets  to  a  method.  Default  input  datasets  are  used  in  case  user  has  not  assigned  a  value. 
This  will  be  helpful  in  cases  where  some  of  the  inputs  (eg.  a  dictionary  )  can  be  understood 
by  default. 

The  MDAS_AD_METH_APPLICATION_REQUIREMENTS  table  captures  all  other  infor¬ 
mation  that  may  be  relevant  and  necessary  when  invoking  the  method.  For  example,  a 
method  may  require  a  large  memory  space  in  order  to  execute  and  this  requirement  may 
be  logged  in  this  table.  Hence,  any  software,  hardware,  protocol  requirements  may  be 
given  as  metadata  in  this  table.  The  MDAS_AD_METH_APPLICATION_PREDICTION 
provides  metadata  to  predict  the  performance  of  a  method.  The  prediction-method Jd 
can  take  parameters  such  as  sizes  of  input  and  provide  a  prediction  about  the  time  re¬ 
quired  by  the  method  to  complete.  This  information  could  be  used  by  a  scheduler  for 
efficiently  using  resources  or  to  reserve  resources  for  later  execution  (see  discussion  of  the 
MDAS_AD_DSET_LOCK  table  earlier.) 


MDA  S-A  D-ME  TH.COM POU ND.ME  T HOD.MA  P 

(mo.method.id  dereferences  MDAS.CD.METHOD 

method.enum 

sub-method-id  dereferences  MDAS.CD.METHOD 

); 

MDA  S-A  D.ME  TH.COM PO  UND.PARA  MET ER.M A  P 

(mo.method.id  dereferences  MDAS.CD.METHOD 

method -param.enum 

sub-method-id  dereferences  MDAS-CD.METHOD 

sub.meth  od.pa  ram.enu  m 

): 

MDA  S.A  D.ME  T H.COMPO  UND.DSE  T.MA  P 
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dereferences  MDAS.CD.METHOD 


(mo .method Ad 
producer.method^enum 
p  rodnee  r\ou  Len  u  m 
consumer jmethod-enum 
consumer Jn^enum 


); 


The  compound  AD  tables  shown  above  provide  the  mapping  between  a  compound  method 
to  its  constituent  sub-methods.  The  MDAS-ADJV1ETH.C0MP0UNDJVIETH0DJVIAP 
table  stores  the  method-to-methods  map  and  also  shows  an  enumeration  of  the  sub-method 
in  the  order  that  they  need  to  be  applied  to  obtain  the  functionality  of  the  compound 
method.  For  example,  assume  that  a  compound  method  cl  consist  of  compile  and  link 
sub-methods  to  be  performed  in  that  order,  then  the  two  methods  are  logged  in  the  table 
with  enumeration  1  and  2. 

The  MDAS_AD_METH_COMPOUND_PARAMETER_MAP  table  maps  the  parameters  given 
for  the  compound  method  to  parameters  required  by  the  sub-methods.  Again  considering 
the  compound  method  cl,  it  will  have  all  parameters  needed  by  its  sub-methods  stored 
in  MDAS_AD_METH_COMPOUND_PARAMETER_MAP.  Some  parameters  of  cl  may  be 
required  by  both  sub-methods  also. 

The  MDAS_AD_METH_COMPOUND_DSET_MAP  table  captures  three  types  of  mappings: 
from  the  compound  method  input  datasets  to  the  input  datasets  of  the  sub-methods,  from 
the  output  datasets  of  the  sub-methods  to  the  output  datasets  of  the  compound  method 
and,  the  interconnection  between  two  submethods,  vdiere  one  of  the  sub-method’s  output 
may  be  the  input  of  another  sub-method.  We  consider  that  the  compound  method  is 
given  an  enumeration  number  0  and  the  sub-methods  are  numbered  from  1  omvards.  The 
compound  method  is  considered  to  be  the  producer  of  input  datasets  and  consumer  of 
output  datasets.  Note  that  a  dataset  (either  input  dataset  or  a.  dataset  that  is  output  by 
a  sub-method)  can  be  used  as  input  by  more  than  one  sub-method.  For  example,  for  the 
data  flow'  diagram  given  in  Figure  4.5  appropriate  mappings  are  captured  in  the  sets  of 
tuples  show'n  in  Tables  4.14  and  4.15;  we  assume  that  the  compound  method  has  24  as  its 
identifier.  Tables  4.14  describes  the  dataset  flow  between  the  sub-methods  of  a  compound 
method  as  well  as  the  usage  of  input  datasets  and  creation  of  output  datasets  by  the  the 
sub-methods.  Tables  4.15  describes  the  usage  of  parameters  by  the  sub-methods.  In  the 
data  flow'  diagram  in  Figure  4.5  a  few  datasets  (output  files)  are  created  by  the  sub-methods 
which  are  not  used  by  other  sub-methods  or  by  given  as  output  datasets.  These  datasets 
are  scratch  files  produced  by  these  methods.  In  MDAS,  we  do  not  keep  track  of  internal 
datasets  created  by  the  sub-methods,  only  the  datasets  that  are  explicitly  outputted  are 
registered.  If  one  needs  to  know'  the  intermediate  datasets,  then  one  can  obtain  them  by 
executing  the  compound  method  and  explicitly  outputting  the  required  datasets. 

The  meta  information  in  the  MDAS_AD_METH_COMPOUND_DSET_MAP  table  can  be 
used  by  an  intelligent  scheduler  to  parallelize  a  compound  method.  For  example,  in  the 
above  method  sub-methods  1  and  2  can  be  performed  in  parallel. 


MDA  S_ .4  D.CONVER  TSIE  THODJD 

(mo.methodJd  Preferences  MDAS.C'D-METHOD 
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mo -method  Jd 

24 

24 

24 

24 

24 

24 

24 

24 

24 


producer-method.enum 

_ 

0 

0 

1 

1 

2 

3 

3 

4 


producer-out-enum 

1 

1 

2 

1 

2 

1 

1 

1 

1 


consu  m  e  r_  method-enu  m 
1 
2 
2 
4 
3 

3 

4 
0 
0 


consumer  .in  .enum 
1 
1 
2 
1 
1 
2 
2 
2 
1 


Table  4.14:  Sample  MDAS_AD_METH_COMPOUND_DSET_MAP  table 


1 

mo.method Lid 

m  e  th  ocLpa  ram.enum 

sub-method-id 

.5  u  b-method-pa  ramjt  n  u  in 

24 

i 

i 

i 

24 

2 

i 

2 

24 

2 

3 

1 

24 

3 

4 

1 

Table  4.15:  Sample  MDAS_4D_METH_C0MP0UND_PARAMETER_MAP  table 


Input 

Datasets. 


Parameters 


Output 

Datasets 


1  2 

1 


►l  i< 

>2  ^  2* 


3  i 


Figure  4.5:  Example:  Data  flow  in  a  Compound  Method 
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moJndataJype 

mo-outdataJype 

); 

M DA  S-A  D.CON  VER  TJ/IE  THOD.  T  YPE 
(  mo-method-type 
moJndataJype 
mo-outdataJype 
); 


The  conversion  tables  given  above  provide  a  means  of  finding  methods  that  are  applicable 
for  conversion  of  a  dataset  from  one  type  to  another.  An  important  aspect  of  MDAS  is 
to  provide  format  transparency .  Hence,  if  a  user  wants  to  print  a  file  that  is  not  in  latex 
format  to  a  Postscript  printer  and  no  replica  of  an  equivalent  file  in  postscript  format  exists, 
then  MDAS  will  use  the  MDAS-ADXONVERT .METHOD JD  table  to  find  appropriate 
methods  that  can  perform  the  format  transformation  before  feeding  the  file  to  the  printer. 
The  MDAS-AD_CONVERTJVIETHOD_TYPE  file  stores  metadata  about  format  conver¬ 
sion.  but  gives  a  class  of  methods  that  can  perform  the  transformation  instead  of  individual 
methods. 

Next  we  discuss  the  schema  of  metadata  tables  for  resources.  Again,  we  do  not  discuss  the 
AD  and  TD  tables  that  have  been  discussed  for  other  types  of  MDAS  elements. 


MDAS-CD-RESO  URGE 
(  mo  ..resource  Jd 
mojreso  urce-name 
mo. re  sou  rceJ  ype _  i  d 
global-authentication  Jd 

); 


The  CD  table  has  similar  functionality  as  the  CD  tables  of  datasets  and  methods.  Note  that 
the  concept  of  a  resource  in  MDAS  is  very  diverse  and  includes  hardware  resources  such 
as  storage  systems,  peripheral  systems,  memory  systems  (such  as  cache),  communication 
systems,  computing  systems,  etc.,  and  software  resources  such  as  operating  systems,  file 
system,  archival  system,  database  systems,  scheduling  systems,  MDAS  systems,  digital 
library  systems,  etc.  The  properties  of  each  special  types  of  resources  are  captured  in 
non-system  SD  metadata  tables. 


MDAS-AD-FUNCTION-ON-RESO  URGE 

(  mo-resource  Jd  dereferences  MDAS-CD-RESO  URGE 

mo.methodJd 
functionJd 
); 

MDAS-AD-RSRC-APPLIGATION-PREDIGTION 

( mo-resource  Jd  dereferences  MDAS-CD-RESO  URGE 

replication-enum 

prediction-method  Jd 

prediction-description 
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); 


The  MDAS_AD_FUNCTION_ON_RESOURCE  table  provides  metadata  about  the  func¬ 
tions  that  can  be  applied  to  each  resource.  For  example,  an  archival  system  may  have 
functions  such  as  open,  close,  create,  read,  write,  seek ,  etc.  Such  functions  are  registered 
in  MDAS  through  this  table  using  the  functioned  attribute.  The  corresponding  TD  table, 
MDAS-TD.RSRC -FUNCTION,  provides  attributes  for  storing  the  name,  a  description  of 
the  function  and  also  whether  it  complies  to  any  standards  (eg.  functions  to  a  DBMS  may 
be  ODBC  compliant,  or  a  parallel  executable  function  may  be  MPI  compliant).  Moreover, 
the  mo. method Jd  in  MDAS_AD_FUNCTION_ON_RESOURCE  table  provides  the  method 
that  needs  to  be  invoked  to  obtain  the  functionality.  This  provides  method  transparency 
when  applying  the  functions  which  can  be  generic  for  resources  of  the  same  type. 

The  MDAS-AD-RSRC-APPLICATION-P REDICTION  table  is  used  to  store  data  that  can 
be  used  to  predict  the  performance  of  each  resource.  We  consider  that  with  proper  parame¬ 
ters  such  as  size  of  datasets,  function  being  applied,  etc.,  one  can  predict  performance  using 
the  associated  prediction  method.  More  than  one  prediction  method  can  be  associated  with 
each  resource. 

Finally,  we  discuss  the  schema  of  metadata  tables  for  users.  We  discuss  the  CD  table  and 
group  AD  metadata  table  only  as  other  tables  are  similar  in  semantics  with  corresponding 
tables  discussed  earlier. 


MDA  S-CD.  USER 
(  mo.user.id 
mo.user.name 
mo  .user. address 
mo-user.phone 
mo. user. phone  2 
mo. user. fax 
mo-user.email 
mo.user.domain 
mo.user.type  .id 
authentication-id 
); 

MDA  5-4  D.  USER.GR  0  UP 

(mo.user.id  ‘preferences  MDAS.CD.USER 

group.user.id  Preferences  MDAS.CD.USER 

): 

The  MDAS-C’D-USER  contains  information  about  users  and  groups.  The  user  type  can  be 
used  to  define  group  hierarchies.  The  semantics  of  authentication  is  similar  to  those  of  other 
elemental  types  in  MDAS.  The  MDAS_4D-USER_GR0UP  table  stores  group  membership 
information. 
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4.9.6  Implementation  Issues 


The  previous  section  demonstrated  the  important  role  played  by  metadata  in  the  MDAS 
architecture  and  also  provided  a  schema  for  the  MDAS  Metadata  Catalog.  This  section 
provides  a  discussion  of  issues  related  to  creating  and  maintaining  this  metadata. 


4.9.6. 1  Generation 

Some  of  the  metadata  recorded  in  the  catalogs  is  provided  directly  by  the  user,  while  other 
metadata  can  be  obtained  automatically  by  pre-processing  the  input  (eg.  data  sets  and 
methods),  actively  searching  for  metainformation  (eg.  resource  discovery)  or,  monitoring 
the  progress  of  an  operation  (eg.  resource  or  process  metadata).  The  system  includes 
mechanisms  to  capture  all  of  these  types  of  metadata. 


4. 9. 6. 2  Representation 

Addressing  issues  related  to  metadata  representation  is  critical  to  the  goal  of  providing 
seamless  integration  of  metadata  across  distributed  heterogenous  systems.  A  metadata 
representation  scheme  must  provide  the  following: 

1.  Convenient  methods  for  inserting,  updating  and  viewing  metadata. 

2.  Ease  of  transportation  of  metadata  among  diverse  distributed  computing  and  storage 
environments. 

3.  Easy  translation  into  various  in-memorv  formats. 

4.  An  inheritance  hierarchy.  For  example,  one  can  define  metadata  about  printers  in 
general,  followed  by  those  for  laser-printers  and  color-matrix  printers,  etc.  followed 
by  metadata  about  specific  printer-types  (eg.  Epson  II  stylus  printer)  and  finally 
metadata  parameters  (eg.  address,  buffer  size  etc)  about  a  specific  printer  attached 
to  a  LAN  or  workstation. 

The  above  representational  issues  will  be  handled  by  defining  a  language  for  representing 
metadata,  called  the  MetaData  Markup  Language  (MDML).  This  language  will  provide  a 
common  distribution  format  for  portability,  and  a  user-friendly  scheme  for  entering  and 
updating  metadata.  The  common  format  will  also  allow  one  to  write  translation  meth¬ 
ods  for  storage  and  memory  representation  at  language-specific  and  system-specific  levels. 
Moreover,  one  can  also  define  a  set  of  methods  that  can  be  applied  to  metadata  that  can 
be  used  for  creating,  maintaining  and  querying  purposes. 


4. 9. 6. 3  Storage 

Since  the  quantity  of  metadata  can  overwhelm  any  system,  it  is  important  to  consider  issues 
related  to  storage  hierarchies,  local  versus  remote  location  of  metadata,  distribution  and 
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fragmentation  of  data,  and  replication.  An  important  aspect  of  metadata  management  is 
the  ability  to  store  and  access  data  based  on  usage  patterns,  archival  requirements,  and 
access  time  requirements.  The  system  must  provide  the  application  an  interface  to  the 
metadata  which  is  independent  of  where  the  data  is  stored  and  how  it  is  managed. 


4. 9. 6. 4  Maintenance 

Important  issues  in  metadata  maintenance  are  fault-tolerance,  schema  evolution,  and  ver¬ 
sioning.  MDAS  catalog  services  must  be  highly  available  and  fault  tolerant  to  ensure  that 
applications  are  not  unduly  disconnected  from  resources.  Schema  evolution  and  versioning 
must  be  supported  since  database  schemas  tend  to  evolve  over  time  and,  at  any  given  in¬ 
stant,  it  is  likely  that  different  resources  available  to  MDAS  are  using  different  versions  of  the 
schema.  Since  the  metadata  schema  and  the  metadata  will  evolve  over  time,  considerations 
for  extensibility  should  be  central  to  the  design. 


4. 9. 6. 5  Retrieval 

The  system  must  support  efficient  retrieval  of  metadata.  Since  the  metadata  catalog  can 
reside  on  different  platforms,  possibly  fragmented  and  replicated,  it  is  neccesary  to  provide 
a  fully-transparent  retrieval  system  that  can  handle  issues  such  as  optimization,  caching, 
sharing,  authentication  and  security.  It  may  also  be  neccesary  to  provide  active  mechanisms 
which  provide  support  for  triggering  an  action  when  a  change  occurs  to  a  specific  piece  of 
metadata. 


4. 9. 6. 6  Legacy  and  Domain-dependent  Metadata 

Finally,  since  there  already  exist  vast  amounts  of  domain-specific  metadata,  defined  by 
various  groups  of  users  (eg.  biologists)  one  needs  to  give  careful  thought  to  the  design  of 
the  system  in  order  to  allow  assimilation  of  existing  metadata  in  the  new  framework.  We 
plan  to  tackle  this  problem  by  providing  automated  means  for  encoding  domain-specific 
metadata  in  a  uniform  manner  and  also  by  porting  existing  metadata  into  the  MDAS 
framework. 
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4.10  Library  and  Catalog  Table  Bindings 


TBD. 


4.11  Low-Level  Interface 


This  section  discusses  the  MDAS  Low-Level  interface  in  detail.  Two  functionalities  are 
supported  here:  drivers  and  internals.  Nothing  at  this  level  is  for  use  by  application  pro¬ 
grams.  Datatypes  unique  to  this  level  are  discussed  in  section  4.11.1.  Function  prototypes 
for  MDAS  drivers  and  internals  are  presented  in  sections  4.11.2  and  4.11.3.  Examples 
concerning  driver  implementations  are  given  in  section  ??. 


4.11.1  Low-Level  Data  Types 
TBD. 


4.11.1.1  MDAS-INIT-STRUCT 


TBD. 


4.11.1.2  MDAS_TICKET_STRUCT 


TBD. 


4.11.1.3  MDAS_DRIVER_STRUCT 


TBD. 


4.11.1.4  MDAS_RSRC_STRUCT 


TBD. 


4.11.1.5  MDAS_RSRCC_STRUCT 


TBD. 


4.11.1.6  MDAS_LLIST .STRUCT 


TBD. 
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Prototype  Name 

Implemented  Name 

Fortran  90 

C,  C++ 

MDAS_*_C0NN 

mdasF_db2_conn 

mdasC_db2_conn 

MDAS_*_DC0N 

mdasF_db2_dcon 

mdasC_db2_dcon 

MDAS_*_GET 

mdasF_db2_get 

mdasCLdb2_get 

MDAS_*_PUT 

mdasF_db2_put 

mdasC_db2_put 

MDAS_*_0PEN 

mdasF_db2_open 

mdasC_db2.open 

MDAS_*_CL0SE 

mdasF_db2_close 

mdasC_db2_close 

MDAS_*_READ_BLK 

mdasF_db2_read_blk 

mdasC_db2_read_blk 

MDAS_*_WRITE_BLK 

mdasF_db2_write_blk 

mdasC_db2_write_blk 

MD AS_  *  _EXEC_TYPES 

mdasF_db2_exec_types 

mdasC_db2_exec_types 

MDAS_*_EXEC 

mdasF_db2_exec 

mdasC_db2_exec 

MDAS_*_CAT_EXISTS 

mdasF_db2_cat_ exists 

mdasC_db2_cat_exists 

MDAS_  *  _CAT_MAKE 

mdas  F  _  db  2  _ c  at .make 

mdasCLdb2_cat_make 

MDAS_*_CAT_DEL 

mdasF_db2_cat_del 

mdasCLdb2_cat_del 

MD AS. *_ INFO .INQUIRE 

mdasF_db2_inf o_inquire 

mdasC_db2_info_ inquire 

MDAS_*_INFO_REGISTER 

mdasF_db2_info_register 

mdasC_db2_inf o_register 

MDAS_*_INFO_UPDATE 

mdasF_db2_info_update 

mdasC_db2_info_update 

MDAS. *_ INFO .PURGE 

mdasF_db2_inf o^purge 

mdasC_db2_info_purge 

Table  4.16:  Driver  function  naming  conventions  for  driver  ‘•db‘2” 

4.11.2  Low-Level  Drivers 

At  the  lowest  level,  MDAS  maintains  a  set  of  architecture  and  resource  specific  drivers. 
These  are  for  internal  use  of  the  MDAS-librarv  Mid-Level  engines  and  daemons,  and  not 
exposed  to  application  programs. 

Currently,  each  driver  contains  about  30  routines.  Depending  on  the  nature  of  the  function 
and  type  of  resource,  these  routines  range  from  low  to  medium  level  of  code  complexity. 
The  argument  lists  for  each  set  of  driver  routines  are  identical. 

All  implementations  must  implement  a  driver  for  the  operating  system  to  be  used  in  the 
run-time  environment.  Built-in  rules  in  the  MDAS  Build  Environment  enforce  this  policy. 


4.11.2.1  Naming  Conventions 


All  Low-Level  prototypes  have  the  prefix  MDAS_*_  where'  *  is  the  driver  name.  Driver  names 
and  the  availability  of  drivers  is  implementation  dependent.  A  translation  table  of  prototype 
names  and  their  actual  names  for  a  “db2”  driver  is  given  in  table  4.16. 
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4.11.2.2  Built-In  Drivers 


Discussion:  TBD. 


4.11.2.3  Access 


MDAS_*_C0NN (user ,  ticket,  server,  comm,  servh,  status) 


user:  (IN) 

ticket:  (IN) 
server:  (IN) 
comm:  (IN) 

servh:  (OUT) 


MDAS.INFOH 
MDAS.INFOH 
MDAS.INFOH 
MDAS. handle 
MDAS. SERVH 


status:  (IN/OUT)  MDAS.status 


status  codes 

type 

meaning 

MDAS.SUCCESS 

success 

connection  established 

MDAS.ERR.COMM 

error 

communicator  operation  failed 

MDAS.ERR.MPI 

error 

severe  MPI  error 

MDAS_ERR_MEMORY 

error 

unable  to  allocate  memory 

MDAS_ERR_TICKET 

error 

access  error 

MDAS.ERR.SERVH 

error 

server  not  available 

MDAS_*_C0NN()  connects  the  user  named  in  user  to  the  service  described  in  server  with 
authorization  protocol  and  key  specified  in  ticket.  The  server  argument  is  guaranteed 
to  describe  1  unique  service.  Likewise,  user  and  ticket  are  guaranteed  to  contain  the 
description  of  1  item. 

If  comm  is  non-NULL,  it  is  guaranteed  to  be  a  valid  communicator  and  MDAS_*_C0NN()  may 
execute  collective  operation  on  comm.  If  comm  is  used  to  establish  an  MPI  intercommunicator 
with  a  remote  service  then  this  new  handle  must  be  cached  in  servh.  If  the  driver  does  not 
use  MPI  protocols,  then  comm  can  be  ignored. 

The  returned  servh  handle  maintains  the  functionality  of  a  physical  connection  across  time¬ 
outs.  The  actual  implementation  may  be  that  in  the  event  of  a  low-level  operation  on  a 
time-out,  the  connection  is  re-instated  by  the  call  responsible  for  the  operation. 


MDAS_*_DCON(servh,  comm,  status) 


servh:  (IN) 

comm:  (IN) 

status:  (IN/OUT) 


MDAS. SERVH 
MDAS. handle 
MDAS. status 


188 


status  codes 

type 

meaning 

MDAS.SUCCESS 

success 

server  deallocated 

MDAS_ERR_COMM 

error 

communicator  operation  failed 

MDAS_ERR_MPI 

error 

severe  MPI  error 

MDAS.ERR.MEMORY 

error 

unable  to  deallocate  memory 

MDAS_ERR_SERVER 

error 

server  not  available 

MDAS_*_DCON()  closes  the  connection  specified  by  servh  and  frees  any  memory  associated 
with  the  structure.  If  MDAS_*_C0NN()  was  used  to  establish  an  intercommunicator,  it  should 
be  released. 


4.11.2.4  Cache  Operations 


4.11.2.4.1  MDAS_*_GET() 

MDAS_*_GET(dset ,  dstkt ,  servh,  comm,  cache,  status) 


dset : 

(IN) 

MDAS.INFOH 

dstkt : 

(IN) 

MDAS.INFOH 

servh: 

(IN) 

MDAS.SERVH 

comm: 

(IN) 

MDAS.handle 

cache : 

(IN) 

MDAS.INFOH 

status : 

(IN/OUT) 

MDAS.status 

MDAS_*_GET()  discussion:  TBD. 


4.11.2.4.2  MDAS_*_PUT() 


MDAS_*_ PUT (cache,  dset,  dstkt,  servh,  comm,  status) 


cache : 

(IN) 

MDAS.INFOH 

dset : 

(IN) 

MDAS.INFOH 

dstkt : 

(IN) 

MDAS.INFOH 

servh: 

(IN) 

MDAS.SERVH 

comm: 

(IN) 

MDAS.handle 

status : 

(IN/OUT) 

MDAS.status 

MDAS_*_PUT()  discussion:  TBD. 


4.11.2.5  Data  Handles 

MDAS_*_OPEN(dset ,  dstkt,  servh,  comm,  mode,  dh,  status) 
dset:  (IN)  MDAS_INFOH 

mode:  (IN)  MDAS.INFOH 
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dstkt : 

(IN) 

MDAS.INFOH 

servh: 

(IN) 

MDAS.SERVH 

comm: 

(IN) 

MDAS.handle 

dh: 

(OUT) 

MDAS.DATAH 

status : 

(IN/OUT) 

MDAS_status 

status  codes 

type 

meaning 

MDAS^SUCCESS 

success 

data  set  open  on  dh 

MDAS_ERR_C0MM 

error 

communicator  operation  failed 

MDAS.ERR.MPI 

error 

severe  MPI  error 

MDAS_ERR_TICKET 

error 

invalid  ticket 

MDAS_ERR_MODE 

error 

invalid  mode 

MDAS_ERR_READ 

error 

read  access  denied 

MDAS.ERR.WRITE 

error 

write  access  denied 

MDAS_ERR_MEMORY 

error 

unable  to  allocate  memory 

MDAS.ERR.SERVER 

error 

server  not  available 

MDAS_ERR_DATASET 

error 

data  set  not  available 

MDAS_*_OPEN()  opens  a  generalized  data  handle  for  data  set  dset  managed  by  the  service 
servh.  The  mode  argument  specifies  the  desired  I/O  mode.  Any  authentication  ticket 
required  for  the  data  set  is  provided  in  dstkt.  The  handle  servh  is  guaranteed  to  be  valid. 
If  comm  is  non-NULL,  it  is  guaranteed  to  be  valid  and  MDAS_*_0PEN()  may  perform  collective 
operations.  If  an  MPI  intercommunicator  is  established  to  perform  the  I/O  operation,  it 
should  be  cached  in  dh.  An  error  is  returned  with  a  NULL  dh  on  failure. 


MDAS_*_CLOSE(dh,  comm, 
dh:  (IN/OUT) 

comm:  (IN) 

status:  (IN/OUT) 


status) 

MDAS.DATAH 

MDAS.handle 

MDAS.status 


status  codes 

type 

meaning 

MDAS.SUCCESS 

success 

dh  deallocated 

MDAS_ERR_COMM 

error 

communicator  operation  failed 

MDAS_ERR_MPI 

error 

severe  MPI  error 

MDAS.ERR.MEMORY 

error 

unable  to  deallocate  memory 

MDAS_ERR_SERVER 

error 

server  not  available 

MDAS_ERR_IO 

error 

I/O  error  on  close 

MDAS_*_CLOSE()  closes  the  data  stream,  etc.  specified  by  dh  (and  possibly  comm)  and  frees 
any  memory  associated  with  the  structure. 


4.11.2.6  Block  I/O 

The  MDAS  drivers  provide  a  basic  block  I/O  facility  for  reading  and  writing  bytes  on  open 
data  handles. 
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MDAS_*_READ_BLK(dh,  count,  buffer,  status) 
dh:  (IN/OUT)  MDAS.DATAH 

count:  (IN)  MDAS.integer 

buffer:  (IN/OUT)  MDAS_handle 
status:  (IN/OUT)  MDAS_status 


status  codes 

type 

meaning 

MDAS.SUCCESS 

success 

bytes  read 

MDAS.WARN.EOS 

error 

found  logical  end  of  stream 

MDAS.ERR.MEMORY 

error 

unable  to  allocate  memory 

MDAS.ERR.SERVER 

error 

server  not  available 

MDAS.ERR.DATASET 

error 

data  set  not  available 

MDAS.ERR.IO 

error 

1/ 0  operation  failed 

MDAS_*_READ_BLK()  reads  count  bytes  from  dh  and  places  them  in  buffer.  A  warning  is 
returned  in  status  if  the  end-of-file,  end-of-stream,  etc.  is  reached. 

MDAS_*_WRITE_BLK ( count ,  buffer,  dh,  status) 
count:  (IN)  MDAS_integer 

buffer:  (IN/OUT)  MDAS.handle 
dh:  (IN/OUT)  MDAS.DATAH 

status:  (IN/OUT)  MDAS.status 


status  codes 

type 

meaning 

MDAS.SUCCESS 

success 

bytes  read 

MDAS.ERR.EOS 

error 

found  physical  end  of  stream 

MDAS.ERR.MEMORY 

error 

unable  to  allocate  memory 

MDAS.ERR.SERVER 

error 

server  not  available 

MDAS.ERR.DATASET 

error 

data  set  not  available 

MDAS.ERR.IO 

error 

I/O  operation  failed 

MDAS_*_WRITE_BLK()  writes  count  bytes  from  buffer  to  dh.  A  error  is  returned  in  status 
if  the  physical  end-of-file,  end-of-stream,  etc.  is  reached. 


4.11.2.7  Executing  Methods 


4.11.2.7.1  MDAS_*_EXEC_TYPES() 


MDAS_*_EXEC_TYPES (server ,  types,  status) 
server:  (IN)  MDAS.INFOH 

types:  (OUT)  MDAS.INFOH 

status:  (IN/OUT)  MDAS.status 


MDAS_*_EXEC_TYPES  discussion:  TBD. 
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4.11.2.7.2  MDAS_*_EXEC() 


MDAS_*_EXEC (method,  params,  server,  ds_in,  ds.out,  status) 
method:  (IN/OUT)  MDAS.INFOH 
params:  (IN/OUT)  MDAS.INFOH 
server:  (IN/OUT)  MDAS_INFOH 
ds.in:  (IN/OUT)  MDAS.INFOH 
ds.out:  (IN/OUT)  MDAS.INFOH 
status:  (IN/OUT)  MDAS.status 


MDAS_*_EXEC  discussion:  TBD. 


4.11.2.8  Catalog  Operations 

MDAS_*_CAT_EXISTS(name,  servh,  status) 
name:  (IN)  MDAS.string 

servh:  (IN)  MDAS.SERVH 

status:  (IN/OUT)  MDAS.status 


status  codes 

type 

meaning 

MDAS.SUCCESS 

MDAS.ERR.SERVER 

MDAS.ERR.CATALOG 

success 

error 

error 

catalog  exists 
server  not  available 
catalog  not  available 

MDAS_*_CAT_EXISTS  ( )  checks  for  the  existance  of  an  MDAS  catalog  named  in  name  on 
servh.  The  caller  may  check  if  the  driver  supports  catalog  functions  by  calling  MDAS_*_CAT_EXISTS() 
with  NULL  for  both  name  and  servh. 

MDAS_*_CAT_MAKE(name,  servh,  status) 
name:  (IN)  MDAS.string 

servh:  (IN)  MDAS.SERVH 

status:  (IN/OUT)  MDAS_status 


status  codes 

type 

meaning 

MDAS.SUCCESS 

MDAS.ERR.SERVER 

MDAS.ERR.CATALOG 

success 

error 

error 

catalog  created 
server  not  available 
catalog  broken 

MDAS_*_CAT_MAKE()  creates  an  MDAS  catalog  named  in  name  on  servh. 


MDAS_*_CAT_DEL(name,  servh,  status) 
name:  (IN)  MDAS.string 

servh:  (IN)  MDAS .SERVH 

status:  (IN/OUT)  MDAS.status 


192 


status  codes 

type 

meaning 

MDAS.SUCCESS 

MDAS_ERR_SERVER 

MDAS.ERR.CATALOG 

success 

error 

error 

catalog  deleted 
server  not  available 
catalog  broken 

MDAS_*.CAT.DEL()  deletes  the  MDAS  catalog  named  in  name  on  servh. 


4.11.2.9  Catalog  Info  Operations 


MDAS.*.INFG_INQUIRE(servh ,  info ,  result , 
servh:  (IN)  MDAS. SERVH 

info:  (IN)  MDAS.INFOH 

result:  (OUT)  MDAS.INFOH 

status:  (IN/OUT)  MDAS. status 


status) 


status  codes 

type 

meaning 

MDAS.SUCCESS 

success 

result(s)  obtained 

MDAS. WARN. RESULT 

warning 

result  is  empty 

MDAS.WARN.SPOOL 

warning 

result  spooled 

MDAS_ERR_MEMORY 

error 

unable  to  allocate  memory 

MDAS.ERR.READ 

error 

read  access  denied 

MDAS_ERR_RESULT 

error 

unable  to  return  result 

MDAS.ERR.SERVH 

error 

server  not  available 

The  catalog  server  connection  servh  is  guaranteed  to  be  valid.  The  Info  argument  info 
is  also  guaranteed  to  be  valid.  The  conditions  and  criteria  argument  may  be  NULL.  A 
valid  handle  is  supplied  to  result,  in  which  any  results  are  returned.  The  result  may  be 
spooled  if  the  magnitude  exceeds  the  driver's  capability.  The  result  must  be  spooled  if  the 
MDAS. SPOOL  directive  (see  MDAS. DIRECTIVE)  is  set  in  cond.  If  the  result  is  spooled,  the 
MDAS.WARN. SPOOL  status  bit  is  set. 

MDAS.*. INFO. REGISTER(servh,  info ,  status) 
servh:  (IN)  MDAS. SERVH 

info:  (IN/OUT)  MDAS.INFOH 

status:  (IN/OUT)  MDAS. status 


status  codes 

type 

meaning 

MDAS.SUCCESS 

MDAS.WARN.REGISTER 

MDAS.ERR.MEMORY 

MDAS.ERR.WRITE 

MDAS.ERR.SERVH 

success 

warning 

error 

error 

error 

info  registered 
info  previously  registered 
unable  to  allocate  memory 
write  access  denied 
server  not  available 
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MDAS_*_INFO_REGISTER()  registers  Info  for  one  MDAS.TYPE.  The  catalog  server  connection 
servh  is  guaranteed  to  be  valid.  The  info  argument  is  also  guaranteed  to  be  valid  and 
contain  at  least  the  minimal  amount  of  required  metadata  for  catalog  registration.  The 
catalog  MDAS. ID  of  the  registered  Info  is  returned  in  info.  If  the  info  is  spooled,  the 
MDAS_WARN_SP00L  status  bit  is  set. 

MDAS_*_INFO_UPDATE(servh,  info,  status) 
servh:  (IN)  MDAS.SERVH 

info:  (IN/OUT)  MDAS.INFOH 

status:  (IN/OUT)  MDAS.status 


status  codes 

type 

meaning 

MDAS.SUCCESS 

success 

info  updated 

MDAS.ERR.MEMORY 

error 

unable  to  allocate  memory 

MDAS.ERR.WRITE 

error 

write  access  denied 

MDAS.ERR.REGISTER 

error 

invalid  MDAS.ID 

MDAS.ERR.SERVH 

error 

server  not  available 

MDAS_*_INFO_UPDATE()  adds  and/or  changes  catalog  Info  for  one  MDAS_ID.  The  catalog 
server  connection  servh  is  guaranteed  to  be  valid.  The  info  argument  is  also  guaranteed 
to  contain  one  MDAS.ID  and  at  least  one  attribute  to  be  added  or  changed.  All  attributes  in 
info  are  assumed  to  be  additions  or  changes.  If  the  info  is  spooled,  the  MDAS_WARN_SP00L 
status  bit  is  set. 

MDAS_*_INFO_PURGE(servh,  info,  status) 
servh:  (IN)  MDAS.SERVH 

info:  (IN/OUT)  MDAS.INFOH 

status:  (IN/OUT)  MDAS.status 


status  codes 

type 

meaning 

MDAS.SUCCESS 

success 

info  purged 

MDAS.ERR.WRITE 

error 

write  access  denied 

MDAS.ERR.REGISTER 

error 

invalid  MDAS.ID 

MDAS.ERR.SERVH 

error 

server  not  available 

MDAS_*_  INFO  .PURGE  ()  deletes  one  or  more  MDAS.ID’s  and  their  associated  Info  in  an  MDAS 
catalog.  The  catalog  server  connection  servh  is  guaranteed  to  be  valid.  The  info  argument 
is  also  guaranteed  to  contain  at  least  one  MDAS.ID  and  no  other  attributes.  All  id#’s  in 
info  should  be' purged.  If  the  info  is  spooled,  the  MDAS.WARN.SPOOL  status  bit  is  set.  If 
one  or  more  MDAS.ID’s  in  info  are  invalid,  the  reponsible  id#’s  are  returned  in  info  and 
the  MDAS.ERR.REGISTER  status  bit  is  set. 


4.11.3  MDAS  Internals 

TBD. 
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4.11.3.1  Parameters  and  Macros 


TBD. 

Need  to  discuss  how  parameter  and  macro  files  are  built  automatically,  what  the  parameters 
and  macros  are,  etc. 

4,11.3.2  Global  Variables 

TBD. 


4.11.3.2.1  MDAS_VERBGSE 


TBD. 


4.11.3.3  Driver  Cross-Reference  Tables 

TBD. 

4.11.3.4  Prototypes 

TBD. 

MDAS_ Init Struct Ct or () 
MDAS_InitStructDtor() 

MDAS.argsO 

MDAS.envO 

MDAS_gethome() 

MDAS_rc2home() 

MDAS_rc2df It () 

MDAS_ val idhome ( ) 


MDAS_getrc() 

MDAS_validrc() 

MDAS_gettickets() 
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MDAS_rc2t ickets ( ) 


MDAS_validtickets() 

MDAS_TicketCtor() 

MDAS_TicketDtor() 

MDAS_DriverCtor() 

MDAS_DriverDtor() 

MDAS_RsrcCtor() 

MDAS_RsrcListCtor() 

MDAS_PurgeRsrcList ( ) 

MDAS_RsrcDtor() 

MDAS_InitRsrcC() 

MDAS_RsrcCCtor() 

MDAS_RsrcCDtor() 

MDAS_ExtendRsrcs() 

MDAS_ExtendTckts () 

MDAS.CmpRsrcs () 

MDAS_CmpTckts 0 

MDAS_TcktListCtor() 

MDAS_PurgeTcktList () 

MDAS.AddRsrcList ( ) 

MDAS.AddTcktListQ 

MDAS_RsrcCCache ( ) 

MDAS.RsrcCPr int ( ) 

MDAS.GetValO 

MDAS.InhaleTxtO 

MDAS_LListCtor() 


MDAS_LListDtor() 


4.12  Demonstration  and  Test  Programs 

(Under  construction.) 


4.12.1  MDAS_INIT()  Test 

/*  testinit.c  */ 

# include  "COPYRIGHT. h" 

#include  "mdasC.h" 

int 

main(  int  argc,  char*  argv[]  ) 

{ 

mdasC_status  status  ; 

mdasC_init(  argc,  argv,  MULL,  status  )  ; 
if  (status [0]  <  0) 

{ 

fprintf (stderr,  "mdasC_example  :  exiting  on  mdasC.init  error\n")  ; 
exit(l)  ; 

> 

if  (status [0]  >  0) 

fprintf (stderr,  "mdasC.example  :  exiting  on  mdasC.init  warning\n") 
exit(0)  ; 

> 

mdasC_f inalize(  NULL,  status  )  ; 
exit(0)  ; 

> 


4.12.2  “View  a  Patent”  Demo 

/*  viewpatent.c  */ 

#include  "mdasC.h" 

int  main(  int  argc,  char  *argv[]  ) 

{ 

/*  feel  free  to  add  comments  to  this  program!  */ 
mdasC.infoh  patinfo  ; 
mdasC_infoh  patsrcs  ; 
mdasC_infoh  viewinfo  ; 
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mdasC_infoh  viewrsrcs  ; 
mdasC_status  status  ; 


/*  initialize  the  MDAS  library  */ 
mdasC_init(argc,  argv,  NULL,  status)  ; 

/*  describe  the  data  set  as  we  know  it  */ 
mdasC.inf o_create(MDAS_DATASET,  patinfo,  status)  ; 
mdasC_inf o_set_attr(MDAS_NAME,  "10001",  patinfo,  status)  ; 
mdasC_inf o_set_attr(MDAS_STOR_GRPN ,  "patent",  patinfo,  status)  ; 


/*  describe  the  display  resources  as  we  know  them  */ 
mdasC_info_create(MDAS_RESOURCE,  viewinfo,  status)  ; 
mdasC_inf o_record_add(MDAS_RSRC_TYPE,  MDAS.DISPLAY, 
viewinfo,  status)  ; 

/*  This  next  record  would  be  taken  as  a  default.  Here 
we  include  it  for  completeness .  */ 
mdasC_inf o_record_add(MDAS_RSRC_LOCT ,  MDAS_L0CAL , 
viewinfo,  status)  ; 

/*  get  the  catalog  entries  that  match  the  patent  description  */ 
mdasC.inquire (patinfo,  NULL,  NULL,  patsrcs,  status)  ; 

/*  get  the  catalog  entries  that  match  display  description  */ 
mdasC.inquire (viewinfo,  NULL,  NULL,  viewrsrcs,  status)  ; 

/*  Pipe  the  patent  to  the  display  method.  PIPE  will  first 
look  for  matches  between  formats  of  patent  replicates 
and  input  formats  of  display  resources  and  select 
one  (data  set,  resource)  pair.  Next,  PIPE  will  call 
MDAS_GET()  to  bring  the  data  set  to  the  local  resource. 
Finally,  pipe  calls  MDAS.EXECQ  to  have  the  local  copy 
of  the  patent  (returned  from  GET  in  "cacheinfo")  displayed. 

*/ 

mdasC_pipe (patsrcs ,  viewrsrcs,  status)  ; 

/*  O.K.,  we’re  done.  */ 
mdasC.f inalize(NULL,  status)  ; 

exit(0)  ; 

> 
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4.13  Build  Environment 


Intro  . .  .TBD. 


4.13.1  Directory  Structure 
TBD. 

MDAS/ 

Makefile 
bin/ 
conf ig/ 
doc/ 
src/ 


4.13.2  Build  Directories 

MDAS  creates  an  architecture-dependent  Makefile  and  binaries  from  common  source  tree. 

For  example,  a  software  build  on  an  IBM  AIX  system  might  create  the  following  MDAS-59 .  AIX  .4.1 

infrastructure  under  the  main  MDAS  directory  tree: 

MDAS/ 

Makefile 
bin/ 
conf ig/ 
doc/ 
src/ 

include/ 

mdas/ 

db2/ 

hpss/ 

http/ 

illustra/ 

MDAS-59. AIX. 4. 1/ 
bin/ 
lib/ 
src/ 

include/ 

. . /src/ include/* 
mdas_drvr .h 
mdas_drvr .F 
mdas  ->  ../src/mdas 
db2  ->  ../src/db2 
hpss  ->  ../src/hpss 
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Compile-time  dependencies  are  determined  by  architecture  resource  files  in  the  MDAS/ conf  ig/ 
directory.  Include  files  named  mdas.drvr .  *  with  contents  specific  to  the  available  languages 
and  resources  are  automatically  generated  in  the  target  include/  directory.  At  run-time, 
parameters  and  an  array  of  function  pointers  defined  in  the  mdas.drvr.*  include  files  are 
used  to  create  the  linkage  between  the  API  and  compiled  driver  functions. 


4.13.2.1  Configuration  Files 
TBD. 

4.13.3  Source  Development 
TBD. 

Need  to  discuss  compile-time  configuration  of  drivers. 


4.13.3.1  API 
TBD. 


4.13.3.2  Mid-Level 


TBD. 


4.13.3.3  Low-Level 


TBD. 


4.13.3.3.1  Drivers 


TBD. 


4.13.3.3.2  Internals 


TBD. 
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4.13.4  Automatically  Generated  Files 


4.14  Executable  Tools 


Executable  versions  of  MDAS  Library  routines  and  miscellaneous  tools  to  assist  with  the 
task  of  Catalog  metadata  registration  are  discussed  here. 

4.14.1  Catalog  Registration 

(TBD). 

One  tacit  assumption  so  far  has  been  that  most  MDAS  library  calls  have  a  command  line 
version  for  use  in  shell  (script)  run-time  environments. 


4.14.2  Catalog  Registration 

(TBD). 

There  was  a  write-up  on  this  in  the  old  MDAS  research  pages  on  the  web. 

The  idea  is  that  there  were  active  and  passive  ”  tools”  to  assist  with  the  registration  of  what 
we  now  call  Catalog  metadata. 

The  active  tools  are  a  set  of  scripts  and/or  executables  to  be  used  for  batch  registration 
of  data  sets.  These  would  be  particularly  useful  for  registering  large  batches  of  files  on 
delivered  on  tape,  etc.  Another  set  of  active  tools  exist  in  the  library  -  primarly  for  building 
interfaces  for  manual  interactive  registration.  For  example,  the  registration  of  a  user  by  a 
system  administrator. 

The  passive  tools  are  library  internals  which  attempt  to  automatically  build  the  minimal 
set  of  metadata  required  to  ’’register”  an  MDAS  entity.  These  tools  are  invoked  passively 
as  the  library  encounters  (or  suspects  the  presence  of)  ’’new”  entities.  For  example,  calling 
MDAS_GET/PUT/COMNECT/EXEC  invokes  the  registration  procedures.  An  advantage  of  this 
approach  is  that  the  metadata  for  an  entity  can  be  grown  with  use;  i.e.,  the  system  ’’learns” 
about  attributes  of  an  entity  over  time.  Caveat:  it  must  start  with  a  minimal  set  of 
attributes. 
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4.15  Agents  and  Brokers 


(TBD). 

Optional  MDAS  agents  and  service  brokers  are  discussed  here. 


4.15.1  The  MDAS  Outreach  Program 

(TBD). 

Cliaitan  has  introduced  a  hybrid  approach  which  involves  an  ’’active”  agent  ’’passively” 
registering  entities  it  discovers  on  some  extent  of  resources.  It  would  seem  that  there  are 
two  functionalities  required  for  a  robust  discovery  mechanism:  a  ’’browser”  and  a  ’’valida¬ 
tor”.  The  former  is  as  Chaitan  describes,  the  latter  is  a  quality  assurance  tool  that  checks 
whether  a  registered  entity  still  resides  and/or  functions  as  described  in  the  catalog.  Since 
MDAS  users  may  want  only  one  of  these  functions,  it  would  make  sense  to  have  two  agents 
(daemons):  mdas_browse  and  mdas_validate. 

This  discussion  sounds  like  a  paper  for  Agents  ’97  (past  due)  or  an  ACM  Transactions 
journal. 

Once  we  have  MDAS  in  place,  a  concern  is  how  we  get  neccesary  up-to-date  metadata  into 
the  system.  While  people  may  be  willing  to  have  MDAS  run  on  their  systems  (for  some 
presumed  advantage  that  they  may  gain  by  doing  this),  they  may  not  be  equally  willing  to 
supply  all  the  metadata  we  would  like  to  have,  in  the  first  place,  and  to  keep  this  updated. 
The  reason  being  that  metadata  collection  could  be  laborious  and  low  on  people’s  priority 
of  things  to  do.  The  suggestion  is  to  think  of  MDAS  metadata  discovery  ’’agents”  which 
go  about  looking  for  metadata  of  interest  to  MDAS  and  update  MDAS  catalogs  with  this 
information. 

There  are,  obviously,  many  details  to  ponder  but,  in  essence,  we  create  agents  for  each  type 
of  resource  and  set  agents  loose  on  the  systems  on  which  MDAS  is  running  or  to  which  it 
has  access.  Depending  on  how  friendly  a  system  (or  sys  admin)  wants  to  be  to  MDAS,  there 
will  be  various  levels  at  which  these  agents  could  be  run,  e.g.  user  level  process,  privileged 
process,  etc.  Depending  on  the  level  (and  how  smart  the  agent  is),  certain  type  and  amount 
of  metadata  can  be  collected. 

I  first  thought  about  the  agent  approach  since  I  was  concerned  that  people  may  not  have 
the  time/resources  to  populate  MDAS  catalogs  with  appropriate  metadata.  However,  the 
basic  concept  can  be  extended  to  glean  lots  of  information  by  monitoring  system  activity. 
In  fact,  systems  like  Andrew  Gross'  intrusion  analysis  s/w  and  the  network  weather  service 
may  be  collecting  all  sorts  of  information  that  may  of  interest  to  MDAS.  Since  the  agents 
embody  MDAS’  efforts  to  include  as  many  resources  into  MDAS  as  possible,  we  can  think 
of  this  as  the  MDAS  Outreach  Program! 
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4.16  File  I/O  Interface  to  Archival  Storage 


This  section  describes  an  early  implmentation  of  a  set  of  MDAS  API’s  which  provide  access 
transparency  to  applications  accessing  data  sets  stored  in  archival  storage  systems.  This 
is  achieved  by  providing  a  common  file  I/O  interface  to  various  archival  storage  systems. 
Thus,  regardless  of  where  a  data  set  resides  (on  disk  or  in  various  archival  storage  systems), 
the  interface  to  access  the  data  set  is  the  same.  As  explained  below,  these  particular  API’s 
do  not  provide  location  transparency  since  location  information  needs  to  be  provided  as 
input  to  them.  However,  the  intent  in  MDAS  is  to  implement  higher  level  API’s  which  can 
query  MDAS  metadata  to  obtain  the  location  information  required  by  the  lower  level  API’s 
described  here.  The  file  I/O  interface  described  here  refers  to  a  particular  implementation 
of  the  interface  at  the  San  Diego  Supercomputer  Center  (SDSC)  which  uses  the  Postgres95 
database  management  system  to  provide  an  interface  to  the  NSL  UniTree  and  the  IBM 
High  Performance  Storage  System  (HPSS)  archival  storage  systems.  NSL  UniTree  is  a 
hierarchical  archival  storage  system  currently  running  in  production  mode  at  SDSC.  The 
system  is  capable  of  storing  almost  unlimited  amount  of  data.  This  system  will  be  replaced 
by  the  HPSS  system  by  the  beginning  of  1997. 


4.16.1  The  File  I/O  API 

Currently,  the  file  I/O  API  specification  includes  the  following  standard  file  I/O  calls, 
create,  open,  unlink ,  stat,  read ,  write,  .seek,  sync,  close,  -stat.  The  function  input/output 
parameters  for  these  functions  are  the  same  as  those  for  the  corresponding  UNIX  calls, 
except  in  the  case  of  the  first  four  functions,  viz.  create,  open,  unlink,  stat.  For  these 
functions,  two  additional  parameters  are  introduced  which  are  described  below. 


New  Parameters. 

The  file  I/O  interface  introduces  two  new  parameters,  access  method  and  host  address, 
which  are  used  to  specify  the  location  of  a  data  set  in  a  distributed  system  which  supports 
replicated  archives.  These  parameters  are  relevant  only  to  functions  that  refer  to  a  file  by 
its  name  rather  than  by  its  file  handle. 


The  Access  Method ”  parameter. 

The  access  method  parameter,  access.m ,  is  used  to  specify  the  access  method  for  stor¬ 
ing/retrieving  data  sets.  The  data  type  is  integer  and  each  integer  value  maps  to  a 
specific  method  of  access.  For  example: 


•  0  -  local  disk 

•  1  -  UniTree 

•  2  -  HPSS 
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The  “Host  Address’'  parameter. 

The  host  address  parameter,  hosTaddr ,  specifies  the  address  of  the  host  system  where  the 
data  resides.  This  provides  support  for  remote  sites  in  a  distributed  system. 


Interface  Functions. 

Following  is  a  list  of  functions  that  together  form  the  file  I/O  interface  to  archival  storage 
systems.  The  prefix  “eJ’  is  used  to  distinguish  these  calls  from  the  standard  UNIX  file  I/O 
calls. 


Functions  with  filename  as  parameter. 


1.  Create . 

int  e_create(int  access_m,  text  *host_addr,  text  ^filename, 

int  mode) 


2.  Open. 

int  e_open(int  access_m,  char  *host_addr,  char  *filename, 

int  flags,  int  mode) 


3.  Unlink. 

int  e_unlink(int  access_m,  char  *host_addr,  char  ^filename) 

4.  St  at. 

int  e_stat(int  access_m,  char  *host_addr,  char  ^filename, 

struct  stat  *statbuf) 


For  example,  the  following  call  to  the  e_create  function  will  create  the  file,  DOCT -archive-file 
on  the  HPSS  archival  storage  system  running  on  host,  suraj.sdsc.edu : 

e_create(2,  "suraj . sdsc . eduH ,  MDOCT_archive_f ileM ,  0) 


Functions  with  file  handle  as  parameter. 

1.  Close. 

int  e_close(int  fd_inx) 

2.  Read. 
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int  e_read(int  fd_inx, 

3.  Write. 

int  e_write(int  fd_inx, 

4.  Seek, 

int  e_seek(int  fd.inx, 

5.  Sync . 

int  e_sync(int  fd.inx) 


char  *buf,  int  len) 


char  *buf,  int  len) 


long  offset,  int  whence) 


4.16.2  A  Prototype  Implementation 

A  prototype  of  the  file  I/O  interface  has  been  implemented  at  SDSC  for  the  NSL  UniTree 
and  IBM  HPSS  systems.  The  Postgres95  database  management  system  was  used  as  the 
front-end  to  this  archival  storage  system.  The  Postgres  DBMS  serves  two  purposes.  First,  it 
provides  a  means  for  storing  metadata  associated  with  the  archival  data  sets  that  are  stored 
in  UniTree/ HPSS.  Using  a  DBMS  allows  one  to  query  the  metadata  using  the  full  power 
of  standard  database  query  language  interfaces.  Second,  the  Postgres  system  provides  the 
means  to  implement  the  functions  specified  in  the  file  I/O  interface  as  internal  Postgres 
functions.  Thus,  applications  can  store/retrieve  archival  data  by  directly  interacting  with 
the  Postgres  DBMS. 


Implementation  using  the  Postgres  DBMS. 

Each  of  the  functions  in  the  interface  is  implemented  as  an  internal  function  in  the  Post¬ 
gres  server .  Corresponding  functions  are  also  implemented  on  the  client  side,  to  support 
client/server  access  to  the  data  sets.  Accessing  archived  data  sets  requires  making  a  connec¬ 
tion  to  the  Postgres  server  from  the  client  using  the  Postgres  CONNECT  API.  Subsequent 
calls  from  the  client  need  to  specify  the  corresponding  “connection  handle”  to  identify  the 
established  connection. 


The  client-side  functions  are  the  same  as  the  corresponding  functions  on  the  server-side  with 
the  addition  of  one  parameter,  viz.  the  Postgres  connection  descriptor  called,  PGconn.  This 
descriptor  is  returned  by  the  call  to  the  CONNECT  API.  For  example,  the  client  function 
prototype  for  create  is  follows: 


int  e.create (PGconn*  conn,  int  access.m,  char  *host_addr, 
char  *filename,  int  mode) 


Authorization. 
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The  file  interface  must  include  checking  to  ensure  that  users  have  the  neccesary  authorization 
to  execute  the  various  functions  on  the  specified  data  sets  in  the  specified  archival  systems. 
Each  function  can  verify  this  for  the  corresponding  user.  In  the  prototype  implementation, 
authentication  is  done  at  two  levels.  User  authentication  is  done  during  Postgres  CONNECT 
processing  to  ensure  users  have  the  authorization  to  connect  to  the  DBMS.  Authorization 
at  the  file  level  is  done  during  file  open  and  create  ( e.open  and  e.create )  processing  to 
ensure  users  have  the  authorization  to  perform  the  specific  I/O  operation.  In  general,  it  is 
expected  that  security  and  authorization  checking  on  data  sets  will  be  done  by  the  ticket 
services  provided  by  MDAS. 


4.16.3  Alternative  Implementations 

In  general,  it  is  expected  that  a  DBMS  will  be  used  to  store  all  the  metadata  associated  with 
an  archival  data  set.  However,  there  are  several  alternative  implementations  for  providing 
access  to  the  archival  data  set  itself.  These  include  storing  the  data  set  as  a  file  under  the 
control  of  a  DBMS,  as  a  large  object  within  a  DBMS,  and  simply  as  an  external  file  (outside 
of  a  DBMS).  These  alternatives  are  further  described  in  the  following  sections. 


DBMS-based  implementations. 

The  DBMS-based  implementations  can  be  divided  into  implementations  that  use  an  “ex¬ 
ternal”  file  implementation  versus  those  that  employ  the  large  object  support  provided  by 
the  DBMS  itself. 


External  file  implementation. 

The  prototype  described  in  this  report  is  an  example  of  a  DBMS-based,  external  file  im¬ 
plementation.  The  DBMS  implements  internal  functions  corresponding  to  the  functions 
specified  in  the  file  interface.  These  functions  are  made  available  to  application  programs 
as  DBMS  API's.  Thus,  application  programs  can  directly  call  these  functions  via  the  API. 
The  application  program  passes  read/ write  buffers  to  the  DBMS  which,  in  turn,  passes 
these  buffers  to  the  archival  storage  system. 


Large  Object  Implementation. 

Object-relational  database  systems  have  various  mechanisms  by  which  they  are  able  to 
support  the  storage  and  manipulation  of  so-called  large  objects  within  a  DBMS.  In  this 
implementation,  the  archival  data  sets  are  stored  as  regular  large  objects  with  the  difference 
being  that  the  DBMS  is  able  to  direct  these  objects  to  archival  storage  systems  rather  than 
storing  them  on  local  disk.  The  functions  specified  in  the  interface  can  be  implemented 
specifically  for  large  objects  within  a  database.  Alternatively,  existing  methods  provided 
by  the  DBMS  for  handling  large  objects  can  be  overloaded  to  handle  archival  data  sets  as 
well. 
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A  Prototype  based  on  Postgres  Large  Objects. 


Postgres95  supports  the  storage  and  manipulation  of  large  objects  within  the  database. 
Thus,  a  prototype  of  the  archival  storage  file  interface  was  implemented  by  extending  the 
existing  Postgres  large  object  implementation  to  allow  for  multiple  storage/access  methods. 
In  Postgres,  each  large  object  is  associated  with  an  object  id  (Oid)  which  is  assigned  when 
the  large  object  is  created.  The  function  prototypes  on  the  DBMS  server  side  are  as  follows: 


Oid  lo_creat(int  access_m) 
int  lo_open(0id  object_id,  int  mode) 
int  lo_unlink(Oid  object_id) 
int  lo_close(int  fd) 

int  lo_read(int  fd,  char  *buf ,  int  len) 

int  lo_write(int  fd,  char  *buf,  int  len) 

int  lo_seek(int  fd,  int  offset,  int  whence) 

Oid  lo_import  (char  ^filename,  int  access.m) 

int  lo_export  (Oid  object.id,  char  *filename) 

Except  for  loJmport  and  lo. export.  these  functions  are  similar  to  the  ones  in  the  external 
file  implementation  and  adhere  to  the  same  UNIX  file  I/O  paradigm.  LoJmport  is  used  to 
import  a  UNIX  file  as  a  large  object  and  lo-export  is  used  to  create  a  UNIX  file  from  a  large 
object.  As  before,  the  access.m  parameter  in  the  lo.creat  and  loJmport  functions  allows 
the  client  to  choose  the  access  method  for  the  large  object  to  be  created. 

As  before,  corresponding  functions  are  implemented  on  the  client  side.  They  are  the  same 
as  the  server  API’s  with  the  inclusion  of  the  the  database  connection  descriptor  parameter 
in  each  case,  e.g. 

Oid  lo.creat (PGconn*  conn,  int  access.m) 


Non-DBMS  Implementation. 

In  a  non-DBMS  implementation,  access  to  the  archival  data  sets  is  provided  by  a  service 
outside  of  the  DBMS  which  supports  the  file  I/O  interface.  Thus,  the  interface  is  imple¬ 
mented  as  a  separate,  stand-alone  service.  As  mentioned  before,  a  DBMS  may  still  be  used 
to  store  metadata  related  to  the  archival  data  sets.  However,  to  access  a  data  set,  the 
application  program  interacts  directly  with  the  service. 
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Chapter  5 


Important  Findings  and 
Conclusions 


The  primary  challenges  in  the  MDAS  project  are  (a)  the  integration  of  data  management 
systems  with  archival  storage  and  (b)  end-user  solutions  for  the  replacement  of  the  (Unix) 
file  paradigm  with  a  higher-order  interface  to  data,  methods,  and  resources.  MDAS  will 
develop  robust  prototype  solutions  to  these  challenges,  but  several  general  problems  will 
remain  that  merit  follow-on  efforts.  These  include: 

Intelligent  Hierarchical  Storage  Systems  :  Current  HSS  technology  is  designed  for  ei¬ 
ther  (a)  atomic  file  input/output  by  many  users  or  (b)  general  read,  write,  and  seek 
operations  by  a  few  users.  An  internal  intelligent  queueing  mechanism  is  desirable  to 
scale  general  I/O  capabilities  to  a  large  number  of  simultaneous  user  requests. 

Software  Development  Environment  Standards  :  The  lack  of  standards  in  system 
software  tools  makes  developing  multi-platform  software  a  tedious  process.  The  fur¬ 
ther  development  and  acceptance  of  POSIX  standards  for  Unix  will  provide  some  relief 
in  this  area.  The  situation  is  particularly  acute  in  high  performance  computing.  In 
1995,  the  NCO  for  HPCC  sponsored  a  report  by  the  System  Software  Tools  Working 
Group  (SSTWG)  on  desired  standards  in  system  software  tools.  Reference  to  this 
report  in  procurements  is  likely  to  have  a  major  effect  on  vendor  compliance. 

Heterogeneous  MPI  :  The  MPI  Forum  is  defining  protocols  which  will  enable  the  com¬ 
munication  of  data-type  structures  and  file  structures  between  third-party  applica¬ 
tions.  Further,  MPI  is  defining  an  interoperable  storage  description  that  will  allow 
the  same  binary  file  to  be  read  by  different  binary  format  computing  platforms.  These 
capabilities  are  restricted  to  applications  running  the  same  version  (implementation) 
of  MPI.  Further,  these  communication  and  storage  modes  are  optional  to  the  user  so 
that  applications  desiring  higher-performance  communication  and  storage  protocols 
may  have  them  on  vendor-specific  architecture.  However,  it  is  likely  that  no  single 
implementation  of  the  MPI  standard  will  run  on  all  platforms  of  interest  to  a  par¬ 
ticular  site:  i.e..  there  is  still  a  need  for  interoperable  implementations  of  MPI.  This 
could  be  acheived  by  defining  an  optional  interoperable  communication  mode  in  the 
MPI  standard  itself. 
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Advanced  OO  technology  :  Object-oriented  (00)  software  technologies  greatly  sim¬ 
plify  the  task  of  software  engineering  and  hold  great  promise  for  software  reuse. 
However,  present-day  00  compilers  do  not  produce  high-performance  executables. 
Improvements  to  both  00  languages  and  compilers  would  be  of  great  benefit. 

Dynamic  Loading  :  A  “just-in-time”  compiled  applet  is  essentially  a  dynamically  loaded 
software  module.  Dynamic  loading  has  existed  in  some  Unix  compiler  technology  for 
several  years,  but  is  not  standard  practice.  It  is  particularly  useful  in  data  mining 
and  analysis  applications  for  compiled  source  code  derived  from  symbolic  mathematics 
and  query  languages.  Dynamic  unloading  is  equally  desirable  when  a  module  is  no 
longer  needed. 

Universal  Resource  Names  :  Scientific  applications  should  be  able  to  access  data  and 
cache  it  locally  no  matter  where  the  data  is  originally  located.  This  is  equivalent  to 
requiring  a  catalog  or  expert  system  with  universal  resource  name  (URN)  capabilities. 

Resource  Discovery  :  Current  0/S  technologies  do  not  provide  adequate  interfaces  for 
resource  discovery.  For  example,  to  “discover”  that  a  particular  DBMS  is  running 
on  a  remote  platform,  the  user  must  perform  manual  work  to  find  the  port  number 
and  appropriate  library  interface.  SNMP  provides  a  partial  solution.  A  general  0/S 
independent  mechanism  for  automated  discovery  is  needed.  Meeting  site  dependent 
security  needs  will  be  an  important  aspect. 

Parallel  I/O  :  Support  for  parallel  I/O  streams  must  be  done  within  the  context  of  emerg¬ 
ing  standards.  This  requires  tracking  the  MPI2  10  effort  which  is  examining  issues 
related  to  message  passing  within  a  compute  platform  and  I/O  to  external  periph¬ 
erals.  Interoperability  between  MPI  and  non-MPI  processes  will  require  specialized 
software  interfaces. 

Distributed  Computation  Support  :  Data  sets  may  be  distributed  to  multiple  plat¬ 
forms,  for  analysis  by  methods  that  are  retrieved  from  a  DBMS.  Support  for  distri¬ 
bution  of  computation  objects  is  needed. 

Third-party  Authentication  :  Methods  and  data  sets  need  to  validate  their  interopera¬ 
tion  through  an  authentication  mechanism  that  is  independent  of  the  local  operating 
system. 

Common  Communication  Layer  :  Many  of  the  above  problems  could  be  solved  by  a 
standardized  communication  layer  that  addresses  concerns  across  all  the  sectors  of 
the  computing  community.  At  present,  there  are  many  protocols  and  software  imple¬ 
mentations  available  with  limited  capabilities  from  which  general  prototypes  can  be 
developed.  The  NEXUS  system  from  Argonne  National  Laboratory  is  example. 


210 


Chapter  6 


Implications 


For  Further  Research 


The  issues  researched  in  MDAS  are  essential  in  enabling  the  ” Distributed  Object  Compu¬ 
tation  Testbed”  project  which  will  build  a  complex  document  handling  system  on  top  of 
federated  databases  that  access  replicated  archives.  The  integration  of  database,  archival 
storage  and  application  (Web  in  particular)  technology  promises  to  facilitate  the  manipula¬ 
tion  of  large  data  sets  and  large  collections  of  data  sets.  One  goal  is  to  enable  data  analysis 
on  terabyte-sized  data  sets  retrieved  from  petabyte  archives,  at  an  access  rate  of  10  GB/sec. 
Current  supercomputer  technology  supports  a  1  GB/s  access  rate  to  1  terabyte  of  disk.  For 
a  teraflops  supercomputer  with  10  TB  of  disk,  data  rates  on  the  order  of  10  GB/s  will  be  fea¬ 
sible.  This  will  require,  however,  support  for  parallel  I/O  streams,  and  support  for  striping 
data  sets  across  multiple  peripherals.  Fortunately,  the  software  technology  to  support  third 
party  transport  of  data  sets  across  parallel  I/O  streams  is  being  developed  in  the  HPSS 
archival  storage  system.  Data  redistribution  mechanisms  for  the  parallel  data  streams  are 
being  standardized  as  part  of  the  MPI-IO  effort.  The  expectation  is  that  the  initial  usage 
prototypes  described  above  can  be  extended  to  support  supercomputer  applications  that 
analyze  arbitrarily  large  data  sets. 
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